# Installing Obsidian in Ubuntu

All the steps, yes even *Profit!*, are required to install from scratch.

To do a manual update, when a new installer is required, only repeat steps 2 to 4.

1. Create a new directory in `~/Applications`

    ```
    $ mkdir ~/Applications/Obsidian
    ```

2. Download the latest `AppImage` from [obsidian.md/download](https://obsidian.md/download?os=linux&arch=x64)

3. Give the file execution permissions

    ```
    $ cd ~/Downloads
    $ sudo chmod +x Obsidian-1.3.4.AppImage
    ```

4. Move the file to the new directory

    ```
    $ mv Obsidian-1.3.4.AppImage ~/Applications/Obsidian/obsidian
    ```

5. Create a desktop file with the following contents and place it in `~/.local/share/applications/Obsidian.desktop`

    ```toml
    [Desktop Entry]
    Type=Application
    Name=Obsidian
    Comment="A second brain, for you, forever."
    Icon=/home/your-user/Applications/Obsidian/icon.png
    Exec=/home/your-user/Applications/Obsidian/obsidian
    Terminal=false
    ```

    NOTE: this also requires an icon saved in the same directory as the AppImage. It can probably  be ignored and it will show a default icon.

6. Validate that the file is correct and install it:

    ```
    $ desktop-file-validate ~/.local/share/applications/Obsidian.desktop
    $ sudo desktop-file-install ~/.local/share/applications/Obsidian.desktop
    ```

7. Profit!

    ![Obsidian installed in Ubuntu](https://photos.collectednotes.com/photos/63/d6bebe98-0ff2-4cbb-a1c7-00ab6b8d0cf1?x-amz-acl=public-read&X-Amz-Expires=3600&X-Amz-Date=20230525T094645Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA5W2WJOHUP7IHVD6I%2F20230525%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=3b9a7ca18aedefc3ae523d410dde815e5fc5564df07f8c2a8e8f65f6d7de7a57)

For more information or questions refer to the forum: [How to use Obsidian AppImage](https://forum.obsidian.md/t/meta-post-linux-tips-tricks-solutions-to-common-problems/6291/3)

All the steps, yes even Profit!, are required to install from scratch.

To do a manual update, when a new instal...

Installing Obsidian in Ubuntu

# Muchachos, ahora nos volvimo' a enloquecer

```
En Argentina nací, tierra de Diego y Leonel
De los pibes de Malvinas que jamás olvidaré
Las finales que perdimos cuántos años las lloré
Pero eso se terminó porque en ahora en Qatar
La final con Mbappe la volvió a ganar papá

Muchachos, ahora nos volvimo' a enloquecer
Porque ganamos la tercera, porque somo' campeón mundial
Y al Diego, en el cielo, lo podemo' ver
Con don Diego y con la Tota, celebrandolo a Leonel

Muchachos, ahora nos volvimo' a enloquecer
Porque ganamos la tercera, porque somo' campeón mundial
Y al Diego, en el cielo, lo podemo' ver
Con don Diego y con la Tota, celebrandolo a Leonel

Somos campeones otra vez
Somos campeones otra vez
```

Muchachos, ahora nos volvimo' a enloquecer
En Argentina nací, tierra de Diego y Leonel
De los pibes de Malvinas que jamás olvidaré
Las final...

Muchachos, ahora nos volvimo' a enloquecer

# Recap of the state management history in React

![DALL·E 3 prompt: Sharp digital depiction of React's state management journey. Starting from the left, a rising sun over a simple landscape represents React's early days. Organized pathways with junctions symbolize Flux, which then merge into a cityscape of interconnected buildings for Redux. A hovering constellation of interconnected celestial bodies embodies GraphQL with Apollo and Relay. Glowing lantern chains signify Hooks, and densely packed atomic orbs represent the newer atomic hooks. The scene culminates with a swirling portal on the right, encapsulating SWR hooks' integration. The artwork is bathed in gentle pastel hues.](https://photos.collectednotes.com/photos/63/24d4ee4f-9850-4cf7-a347-623da81c455f?x-amz-acl=public-read&X-Amz-Expires=3600&X-Amz-Date=20231019T160852Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA5W2WJOHUP7IHVD6I%2F20231019%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=42322f5a4c6f69538d271d0b2a398bdf9c11c3afaf91f5ac86d70f677fa00d6d)

> This post was originally a note on my [Digital Garden 🌱](https://publish.obsidian.md/gillchristian)

**Disclaimer**: this is wildly inaccurate, I’m just writing it down from memory as a recap of where we came from to better understand where we are at today and what could come next.

## Wild West

When React was first introduced it was advertised as the V in MVC. For those that don’t know, MVC stands for Model-View-Controller, in other words, React’s initial concern was only about the view.

These were the days of `createClass`. See [React Without ES6](https://reactjs.org/docs/react-without-es6.html) if you have no idea what I’m talking about.

People were using React as the view layer on top of other frameworks like Backbone or even Angular.js 🤪 My guess is even Facebook had no idea what to do about state in React those days.

Two way data binding and DOM mutations were the way people managed state updates at the time.

## Flux

Then came [Flux](https://facebook.github.io/flux/).

> Application Architecture for Building User Interfaces

Yay we were saved! There was finally a way to manage state for React applications that made sense.

The problem with Flux is at the moment it was only an architecture pattern, there was no library. You had to build your own. I remember using [bloody-flux](https://www.npmjs.com/package/bloody-flux/v/1.0.0) for an small side project. Which turns out is still up an running on GitHub Pages: http://gillchristian.github.io/patriarchs-timeline.

## Time travel 🚀

Then Dan Abramov [introduced Redux on react-Europe 2015](https://youtu.be/xsSnOQynTHs) 🤯

Redux [took some really cool ideas](https://redux.js.org/understanding/history-and-design/prior-art) and brought them to React. And together came the possibility of fancy tooling. I remember the first time I tried time travel debugging, it was so cool! Your Angular.js application couldn’t do that!

Around the same time some other state management alternatives, like MobX, started to show up.

Redux itself became a whole thing, it inspired other frameworks like Vue and Angular to adopt similar patterns.

Since it was a relatively low level tool, just like React, that gave a lot of freedom to the user to find different ways to make it work for them. In particular when it came to async operations Redux itself gave no official solution. The most popular options are [redux-thunk](https://github.com/reduxjs/redux-thunk), [redux-observable](https://redux-observable.js.org/), and [redux-saga](https://redux-saga.js.org/). There were probably a dozen more options out there.

The problem with Redux was how verbose it could get to have all your state in there. And messing up the performance of the application was relatively easy as well.

## GraphQL as state management?

Then another technology from Facebook showed up and became popular. The hype was real, GraphQL would save us! From the perfectly fine and working RESTful approach to developing APIs that is.

With the GraphQL revolution people realized that for plenty of applications data fetching is so coupled with state management that it was probably a good idea to marry the two into a single ~~abomination~~ solution. And thus [Apollo](https://www.apollographql.com/) and [Relay](https://relay.dev/) showed up.

GraphQL never seemed like a great thing to me, probably because I never faced the problems it’s meant to solve. And so I never got into Apollo or Relay, so that’s all I can say. ¯\\\_(ツ)_/¯

## Hook me up, would ya?

Up until this point people would swear by the separation between [presentational and container components](https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0), also called dumb and smart components.

The idea was that some components should care only about the presentation and others about the logic. Presentational components would not have any kind of logic or state and concern not with the model of the application, after all they were truly dumb. Container components, on the other hand, were the smart ones, all the state, interactions with the model, subscription to Redux, etc. would happen there and they would just render a single presentational component.

In other words, separation of concerns. Problem was people took it very seriously, I’ve had PR rejected and blocked because a component that was rendering a piece of UI also had some local state in it, say a toggle, that had no effect in the rest of the application. As you can see I’m still salty about it 😂

At this point hooks showed up and the line started to blur, a lot, to the point there was no line anymore. Hooks made it super easy to reuse logic and any component that needed that logic could use it. There’s still a need for highly reusable presentational components, of course, but nobody talks about containers anymore.

With the introduction of hooks and the PTSD people suffered from how verbose Redux can become devs started to write more and more local state.

There was no need to convert a functional component to a class to add state, that, I think, is what made the whole difference. There was no friction, only a `useState` away from it.

However local state is not a silver bullet. Nothing is, besides actual silver bullets, those used to kill a werewolf or witch.

The problem with local state, whether it is with hooks or not, is that whenever another part of the application that isn’t down the three where the state is defined needs that piece of state it forces the state to be moved up to a common parent.

It is not possible for `X` to access the state defined in `A`.

![react component tree state dependencies](https://photos.collectednotes.com/photos/63/c8214f14-1d3b-4212-b43f-e650292be247)

Instead we have to move the state up to a common parent.

![react lift state](https://photos.collectednotes.com/photos/63/e38ecc28-0928-4527-a211-1accc084c19e)

Do this process several times and you are suddenly longing for Redux again.

Context does solve this problem, but just like Flux, it’s a very low level solution and defining context by hand tends to be messy and verbose. *Ain’t nobody got time for that!*

## Going Atomic

This is when solutions like [Recoil](https://recoiljs.org/) and [Jotai](https://jotai.org/) come into play. The elevator pitch is: *imagine if `useState` was global*.

By defining this *atom* data structure one is able to share state between different parts of the component three without the need to lift state up to the common parent.

Boom 💥 any component can access the same state!

![react use atom](https://photos.collectednotes.com/photos/63/c58bb5a2-da55-4a3f-be34-c3b5e3b4c82e)

If I’m not mistaken these [ideas of *atoms* come from Clojure](https://clojure.org/reference/atoms).

## State is a job for the ~~feds~~ fetching

Remember coupling the state management and data fetching layers together? Turns out that we don’t need GraphQL for that.

Libraries like [react-query](https://react-query-v3.tanstack.com/) and [SWR](https://swr.vercel.app/) offer a very thin layer around data fetching that is able to manage your state as well. Or at least the state that has to be fetched from some remote location.

This approach can be seen as an inversion of control, instead of having the state management layer take care of the data fetching in some way or another, we now have the data fetching layer taking care of the state.

By leveraging caching strategies, like `state-while-revalidate` (that’s where SWR name comes from), this libraries can return (stale) data quickly and swap it for the fresh one once the new request resolves.

From [SWR](https://swr.vercel.app/) docs:

> With SWR, components will get a stream of data updates **constantly** and **automatically**. And the UI will be always **fast** and **reactive**.

From [react-query](https://react-query-v3.tanstack.com/) docs:

> Fetch, cache and update data in your React and React Native applications all without touching any "global state".
> 
> React Query […] in more technical terms, it makes **fetching, caching, synchronizing and updating server state** in your React applications a breeze.

## What’s next?

I don’t know what interesting, revolutionary, and wheel-reinventing pattern will become popular next. But all we can do is wait and be ready to rewrite our applications when that happens.

Or, maybe, come up with another pattern ourselves to speed up the process 😎

DALL·E 3 prompt: Sharp digital depiction of React's state management journey. Starting from the l...

Recap of the state management history in React

# Generic discriminated union narrowing

![DALL·E 3 prompt: Sharp digital drawing symbolizing the concept of 'Generic discriminated union narrowing' in TypeScript. The left side showcases various geometric shapes, each representing a different data type or union. As we move to the right, a funnel structure appears, narrowing down and filtering these shapes into a single, refined form, illustrating the process of narrowing. This transformation is accentuated by interconnected lines and nodes, highlighting the connections and relationships. Soft pastel colors provide a harmonious backdrop, underscoring the elegance and precision of TypeScript's capabilities.](https://photos.collectednotes.com/photos/63/fdbb62a3-5149-47ef-bbff-3363c32dad3f?x-amz-acl=public-read&X-Amz-Expires=3600&X-Amz-Date=20231019T161419Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA5W2WJOHUP7IHVD6I%2F20231019%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=b8f6876eca2b9addfc976a68f378c28d8155531918258175e43013b904f5a4fe)

> This post was originally a note on my [Digital Garden 🌱](https://publish.obsidian.md/gillchristian)

When working with discriminated unions, also known as tagged unions, in [TypeScript](https://publish.obsidian.md/gillchristian/Research/TypeScript) one often has to narrow down a value of the union, to the type of one of the members.

```ts
type Creditcard = {tag: 'Creditcard'; last4: string}

type PayPal = {tag: 'Paypal'; email: string}

type PaymentMethod = Creditcard | PayPal
```

Given the above type, we would want to either check that a value is of PayPal type to show the user's email or Creditcard type to show the last 4 digits.

This can be do simply but checking the discriminant property, in this case `tag`. Since each of the two members of the `PaymentMethod` type have different types for the `tag` property, TypeScript is able to, well, discriminate between them to narrow down the type. Thus the *tagged union* name.

```ts
declare const getPaymentMethod: () => PaymentMethod

const x = getPaymentMethod()

if (x.tag === 'Paypal') {
  console.log("PayPal email:", x.email)
}

if (x.tag === 'Creditcard') {
  console.log("Creditcard last 4 digits:", x.last4)
}
```

To avoid this explicit check of the `tag` property you might define [type predicates](https://www.typescriptlang.org/docs/handbook/2/narrowing.html#using-type-predicates), or guards.

```ts
const isPaypal = (x: PaymentMethod): x is PayPal => x.tag === 'Paypal'

const x = getPaymentMethod()

if (isPayPal(x)) {
  console.log("PayPal email:", x.email)
}
```

The problem with such guards is they have to be defined for each member of each discriminated union type in your application. Or *do they*?

If you are like me you probably wonder how to do this generically for all union types. Could this be even possible with some TypeScript type level black magic?

The short answer is yes.

```ts
const isMemberOfType = <
  Tag extends string,
  Union extends {tag: Tag},
  T extends Union['tag'],
  U extends Union & {tag: T}
>(
  tag: T,
  a: Union
): a is U => a.tag === tag
```

The proper response is, what the ~~f\*ck~~ ~~heck~~ hack?

Ok, let me explain.

We need four generic types, in practice the caller will not need to pass these, they are there with the purpose of allowing TypeScript to do its type inference business.

Notice that for all of them we are not allowing any type but instead using `extends` to inform TypeScript that those generic types should meet certain conditions.

- `Tag` is the union of all the tags of `Union`, it should extend the base type of our tag, in this case `string`
- `Union` is our tagged union type, it has to be an object with a `tag` property of type `Tag`
- `T` is the specific tag we want to narrow down with, and thus it should extend the `Tag` type
- And `U` is the specific member of `Union` we want to narrow down to, it should extend the `Union` and its tag should be `T`, the specific one we want

`Tag` and `Union` are there to define the union type we want to narrow down from and `T` and `U`, for the ~~lack~~ laziness of finding better names, are where the magic happens since they are the narrowed down types we expect to get to.

```ts
const x = getPaymentMethod()

if (isMemberOfType('Creditcard', x)) {
  console.log('Creditcard last 4 digits:', x.last4)
}

if (isMemberOfType('Paypal', x)) {
  console.log('PayPal email:', x.email)
}
```

*Et voilà*, it works!

![inferred creditcard type](https://photos.collectednotes.com/photos/63/7529fd81-1138-4360-a81a-c87d65fbd4bd)

And this is how TypeScript fills in the *holes* of the generics.

![inferred type arguments](https://photos.collectednotes.com/photos/63/ff441eb1-e044-4e22-97b1-2821742c1452)

There's a variation of `isMemberOfType` that I like to use which works as a sort of getter instead of type predicate.

```ts
const getMemberOfType = <
  Tag extends string,
  Union extends {tag: Tag},
  T extends Union['tag'],
  U extends Union & {tag: T}
>(
  tag: T,
  a: Union
): U | undefined =>
  isMemberOfType<Tag, Union, T, U>(tag, a) ? a : undefined
```

The usage is similar, but it requires a null check, of course.

```ts
const cc = getMemberOfType('Creditcard', getPaymentMethod())

if (cc) {
  console.log('Creditcard last 4 digits:', cc.last4)
}

const pp = getMemberOfType('Paypal', getPaymentMethod())

if (pp) {
  console.log('PayPal email:', pp.email)
}
```

There’s a little problem, the inferred type it returns is not so nice, since it's based on our definition of the generic (`U extends Union & {tag: T}`).

![inferred returned type of getter](https://photos.collectednotes.com/photos/63/bf825eb9-a82c-490e-b893-9c835e7b5db7)

In practice this is not a problem, but since we got this far, we can keep going, right?

Enter [Extract<Type, Union>](https://www.typescriptlang.org/docs/handbook/utility-types.html#extracttype-union), one of TypeScript's type utilities:

> Constructs a type by extracting from `Type` all union members that are assignable to `Union`.

For example, in the following case `T0` will be of type `'a'`:

```ts
type T0 = Extract<'a' | 'b' | 'c', 'a' | 'f'>
```

The definition is simple:

```ts
// Extract from Type those types that are assignable to Union
type Extract<Type, Union> = Type extends Union ? Type : never
```

![slaps roof of car meme](https://photos.collectednotes.com/photos/63/204e9c1d-c050-433a-a583-be737ff70fe6)

With our current definition of `isMemberOfType` and `getMemberOfType`, the returned type extends union: `U extends Union & {tag: T}`.

In the case of PayPal it would be `PayPal & { tag: 'PayPal' }`. By adding `Extract` to the returned type we can get `PayPal` instead.


```ts
const isMemberOfType = <
  Tag extends string,
  Union extends {tag: Tag},
  T extends Union['tag'],
  U extends Union & {tag: T}
>(
  tag: T,
  a: Union
): a is Extract<Union, U> => a.tag === tag

const getMemberOfType = <
  Tag extends string,
  Union extends {tag: Tag},
  T extends Union['tag'],
  U extends Union & {tag: T}
>(
  tag: T,
  a: Union
): Extract<Union, U> | undefined =>
  isMemberOfType<Tag, Union, T, U>(tag, a) ? a : undefined
```

![better inferred return type](https://photos.collectednotes.com/photos/63/78d2280d-a28a-4be3-9cec-6e4bd264a615)

Much cleaner this way! Now I can sleep in peace …

In conclusion, we went from simple discriminant property check to a monstrosity of generics and type inference that achieves the same thing. Should you use these utilities in production? ~~Of course! Even more so if it will confuse our colleagues.~~ Maybe not, but it was fun to discover some of the cool stuff we can achieve with TypeScript.

[Here's the final version of the examples in the TypeScript Playground](https://tsplay.dev/NBRQbN).

DALL·E 3 prompt: Sharp digital drawing symbolizing the concept of '' ...

Generic discriminated union narrowing

# Stream, Season 2

![phone with twitch app](https://photos.collectednotes.com/photos/63/12d1781b-8bc8-45e1-8992-26ec7e08bde8)

A few weeks ago I started to stream again after taking a break for a couple of months. I'm now on Season 2 of the stream.

## Why?

I started to stream in 2020. Around May, if I remember correctly.

I remember back in 2015 I discovered programming streams, think it was on [livecoding.tv](https://blog.educationecosystem.com/livecoding-tv-watch-people-code-products-live/). I'd watch and think that one day I would stream myself. Took me a few years, but I did it xD

To be honest I don't even know why I decided to stream. What I do know is that as awkward as my streams are, I enjoy doing it.

## Season 1

Season 1 was random. Like a TV Show that producers aren't sure if there's going to be another season or not.

It was mostly about Functional Programming and doing whatever I felt like doing. I tried out a few things that never finished like [the Fantasy Land series](https://www.youtube.com/watch?v=EA9-Ov7kkfY&list=PLEhkZhBLBv83FdvJXb3p2XMSDXLx03uw0) and [working through books](https://www.youtube.com/watch?v=tuaP7Nn1Buw&list=PLEhkZhBLBv83fvFQ3XrM0o50UMGNGyHZW).

Here are some other things I did:

- Learn PureScript and build a few things with [Halogen](https://publish.obsidian.md/gillchristian/Knowledge/Halogen)
- A [tool to generate PureScript identifiers for all the Tailwind classes](https://github.com/gillchristian/tailwind-purs).
- Automate some of my stream setup ([gillchristian/strem](https://github.com/gillchristian/strem)). So meta!
- Build the UI of [Listas](https://publish.obsidian.md/gillchristian/Projects/Listas) with Halogen and Tailwind.

I also uploaded some of the [VODs to YouTube](https://www.youtube.com/channel/UCffp5zsEcCty7DVric3QEuw), which some people found very useful. I should probably do more of that.

Eventually I got tired of it, I figure because I had no goal in mind. Every week would be a new random thing.

And also, during this time I moved to a new place and have been busy with a ton of renovation projects, which make up a big chunk of my free time now. Maybe I should stream that?

## Season 2

Time passed by and I started to miss the stream. I felt like break was over. And so I decided to start again. Since I had quite some time to think about the stream, instead of you know, actually streaming, I realized that I need to set a goal for the stream. Or at least a theme to stick to. Something that would keep me motivated, hold me accountable, and give purpose to it.

While Season 1 was all random and doing whatever, Season 2 is going to be about figuring out what the hack do I want with my stream.

The main thing I'm changing already is the randomness of it. For the foreseeable future I will stick to a single project at a time. At the moment it is [therssproject](https://therssproject.com/). I'm not sure what will be next. But I do want to take a more *indie hacker* approach on my side projects from now on, and that will reflect on the stream as well.

I would like to grow my audience as well. The days I had the most fun on the stream where when people showed up and it wasn’t just me.

One recent thing that really got me inspired is [@ThePrimeagen](https://twitter.com/theprimeagen)'s video [Why I make Content](https://www.youtube.com/watch?v=7FsyXTMLPBY). I hope to be able to share that passion for programming as well!

See you on [twitch.tv/gillchristian](https://www.twitch.tv/gillchristian)! 


phone with twitch app

A few weeks ago I started to stream again after taking a break for a couple of months. I'm now on Season...

Stream, Season 2

# A day in the life of a software engineer

![DALL·E 3 prompt: atercolor artwork of a software engineer relishing a work-from-home day. The scene spans the entire canvas, depicting the engineer at a neat home desk, surrounded by bookshelves and a window that offers a glimpse of a tranquil outdoor setting. Adjacent to the desk, a comfortable couch invites relaxation during breaks. A fireplace radiates warmth in the room, and a fluffy Samoyed dog is curled up in a ball nearby, adding to the coziness. The composition is painted in soft pastel tones, emphasizing the serene and nurturing ambiance of a home workspace.](https://photos.collectednotes.com/photos/63/b9eec1c2-cef5-4db6-a597-9e10b021b511?x-amz-acl=public-read&X-Amz-Expires=3600&X-Amz-Date=20231019T162141Z&X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIA5W2WJOHUP7IHVD6I%2F20231019%2Fus-west-2%2Fs3%2Faws4_request&X-Amz-SignedHeaders=host&X-Amz-Signature=b1f790bae9ac645402c3254d5f03de7354e4d256c8bfa5a2513e7e0a3a095bf1)

What's like to work as a software engineer? In a nutshell you'll write code to solve problems and collaborate on meetings. Of course it's more complicated than that.

There are plenty of videos and articles on the internet about what the day of the a software engineer looks like. Instead of going doing yet another of those, I want to share what key aspects for me.

## Your mileage may vary

Although there are constants, software development jobs are all different. Some companies have more meetings than actual development time, some only communicate through documents ([like Gumroad](https://sahillavingia.com/work)), some emphasize the social aspects while others are just about work.

## Solving problems

Software engineering is about solving problems. That's it, that's the Tweet.

Technical problems like how to make a build tool work for your project's setup or optimizing the performance of an algorithm to be fast enough and product problems which always revolve about making a better experience for your users.

## Communication is key

Computers are the easy part. Humans and communication are the hard part. Learn to communicate. You will never work in completely isolation. There are clients, managers, colleagues from all sorts of domains, candidates to interview.

Communication involves listening and understanding what others are trying to say, and expressing yourself clearly so other can understand your point of view.

## Learning

Technology is always changing. That's a constant. Which means you'll never be able to stop learning. Those that embrace the constant learning do better.  [Learn how to learn](https://jamie.build/learning-how-to-learn.html).

## Flexibility & Opportunities

Software engineering, and tech in general, is a very flexible industry. Although some jobs lean more on the traditional 9 to 5 approach.

Maybe you want to only work 4 days a week, or prefer to start your day super early and have the afternoon free. You might want to work for a company that is doing some good impact in the world and resonates with you, you might want to move to another city, country or continent. There are plenty of opportunities in this field, find what works for you.

## Formalities

It's not all fun and games, there are boring parts of the job as well. It's a job after all. Filling reports, attending meetings that could've been and email. But since you are getting paid to do it ¯\\\_(ツ)_/¯

DALL·E 3 prompt: atercolor artwork of a software engineer relishing a work-from-home day. The scene spa...

A day in the life of a software engineer

# Code Reviews Comments Convention

A convention to clarify the intention of a comment in a Pull Request (PR) review using prefixes.

![xkcd standars](https://photos.collectednotes.com/photos/63/9be36614-4d0b-4c70-98f7-2ffab8ae783c)

*[Mandatory xkcd](https://xkcd.com/927/)*

Although it is possible to express the intent in the way the comment is written, it is easier to do so with a simple prefix. Not only it requires less words but it is also easier to take a quick look at the comments and understand what is the intention/meaning of each one.

My rule of thumb is, only reviews that include `[req]` and/or `[q]` should _Reject_ the PR. In other cases just make the review a _Comment_ or _Approve_.

## Prefixes

**`[req]` (requested change)**

Reviewer *believes* something should be changed.

**`[nth]` (nice to have)**

Reviewer suggests something better/more thorough/common pattern etc.

**`[pp]` (personal preference *of the reviewer*)**

This shows own opinion on style/unification etc. Might influence the author to apply some changes, but does not provide any benefits (it's not for optimization/better interfaces etc.)

**`[q]` (question)**

Reviewer would like to get some explanation on topic.

**`[fixed]`**

Author fixed/changed based on the comment.

**`[wont-fix]`**

Author declines the request. It should be first discussed with reviewer and explained in comment.

## Credits

To whoever came up with this convention 😅

If you know let me know, so I can credit & thank them! 🙏

---

**Happy and safe coding** ✌️

A convention to clarify the intention of a comment in a Pull Request (PR) review using prefixes.

xkcd standars...

Code Reviews Comments Convention

# Composing predicates

A few days ago I was writing some validation functions that were basically a composition of several other predicates.

Which would look something like this:

```hs
predA :: a -> Bool

predB :: a -> Bool

predC :: a -> Bool

predABC :: a -> Bool
predABC a = predA a && predB a && predC a
```

A Haskeller would be bothered by having to manually pass `a` to all the predicates. A **true** Haskeller would not, probably. But I'm far from that level of enlightenment. So I decided to find a way to compose predicates.

Note that by compose I mean not function composition but to combine two predicates together to get a new one. Either by conjunction (`&&`) or disjunction (`||`).

## Monoids

Since Monoids let us combine things, they were bound to show up in my search.

As we said, booleans (and predicates) can be combined in more than one way, so there isn't a default Monoid instance for Bool.

`Data.Monoid` defines:

- [All](https://hackage.haskell.org/package/base-4.14.0.0/docs/Data-Monoid.html#t:All) for conjunction.
- [Any](https://hackage.haskell.org/package/base-4.14.0.0/docs/Data-Monoid.html#t:Any) for disjunction.

```
λ> getAll (All True <> All False)
False
λ> getAll (All True <> All True)
True
```

```
λ> getAny (Any True <> Any False)
True
λ> getAny (Any False <> Any False)
False
```

Since the goal is to compose not booleans but predicates, we need to some mapping and folding to achieve that.

```hs
predABC :: a -> Bool
predABC = getAll . foldMap (All .) [predA, predB, predC]
```

```
λ> predABC a
True
λ> predABC b
True
λ> predABC z
False
```

Success? Well, it works and we can add as many predicates as we like with very low effort. But to compose just three predicates I'm not sure if it's worth.

## Applicative

If there are two ways to do this, there has to be a third.

From [#100DaysOfFP Day 33]( https://twitter.com/gillchristian/status/1229705223419105281)

> [Applicative instance of (->) functions](https://hackage.haskell.org/package/base-4.14.0.0/docs/src/GHC.Base.html#line-973) allows to apply an argument (x) to two unary functions (f & g) and then apply the result of each to a third function (h) to produce the result (y).

![applicative functions](https://photos.collectednotes.com/photos/63/4ba32968-eb68-487a-b46d-b379461d96a3)

That's exactly what I want!

```hs
(&&&) :: (a -> Bool) -> (a -> Bool) -> a -> Bool
f &&& g = (&&) <$> f <*> g

(|||) :: (a -> Bool) -> (a -> Bool) -> a -> Bool
f ||| g = (||) <$> f <*> g
```

Composing the predicates is way simpler now

```hs
predABC :: a -> Bool
predABC = predA &&& predB &&& predC
```

And is possible to use both combinators. Which was not possible with Monoids (*most probably is possible but not as straightforward*).

```hs
predAandBorC :: a -> Bool
predAandBorC = predA &&& predB ||| predC
```

Yup, I'm going to stick with those for combining my predicates 😏

One more thing, I declared the types of `(&&&)` and `(|||)` specified for the function instance of applicative. But they could work with any applicative.

```hs
(&&&) :: Applicative f => f Bool -> f Bool -> f Bool
f &&& g = (&&) <$> f <*> g

(|||) :: Applicative f => f Bool -> f Bool -> f Bool
f ||| g = (||) <$> f <*> g
```

```
λ> (Just True) &&& (Just False)
Just False
λ> (Just True) &&& (Just True)
Just True
λ> (Just False) &&& (Just False)
Just False
```

Yet another thing. `liftA2` could make the implementations even shorter.

```hs
(&&&) :: Applicative f => f Bool -> f Bool -> f Bool
(&&&) = liftA2 (&&)

(|||) :: Applicative f => f Bool -> f Bool -> f Bool
(|||) = liftA2 (||)
```

---

**Happy and safe coding** 🦄



A few days ago I was writing some validation functions that were basically a composition of several other predicates.

Whic...

Composing predicates

# Crossposting to dev.to

Last week [I migrated all my articles from dev.to](https://collectednotes.com/gillchristian/from-dev-to-to-collected-notes). I wrote a Haskell script to do that (duh!)

Although I'm posting in CollectedNotes now I do want to continue crossposting on [dev.to](https://dev.to/gillchristian). So is time for another script 🤓

## The Script

Very similar to the previous one. But now it accepts a few config options like the dev.to article series, tags and what article to publish (defaulting to the latest public one).

👇 *The help text produced by optparse-applicative*

```
$ ./collected-to-dev.hs --help
Post a note from CollectedNotes to dev.to

Usage: collected-to-dev.hs --site-id SITE_ID --email EMAIL --token TOKEN
                           --api-key API_KEY [--publish] [--tags TAGS]
                           [--series SERIES] [--note NOTE_SLUG]

Available options:
  --site-id SITE_ID        CollectedNotes notes site ID
  --email EMAIL            Your CollectedNotes email
  --token TOKEN            CollectedNotes API Token
  --api-key API_KEY        dev.to API Key
  --publish                Publish the article (creates as a draft by default)
  --tags TAGS              Comma separated list of tags (max 4)
  --series SERIES          dev.to article series
  --note NOTE_SLUG         The path of the note to publish
                           (collectednotes.com/my-site/<NOTE_SLUG>). If missing
                           the latest note will be published
  -h,--help                Show this help text
```
`collected-to-dev.hs` ([see on GitHub](https://github.com/gillchristian/scripts.hs/blob/master/collected-to-dev.hs))

```hs
#!/usr/bin/env stack
{- stack
   script
   --resolver lts-13.27
   --package aeson
   --package sort
   --package lens-aeson
   --package wreq
   --package lens
   --package text
   --package bytestring
   --package parsec
   --package optparse-applicative
-}

{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE DeriveGeneric #-}
{-# LANGUAGE LambdaCase #-}
{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE RecordWildCards #-}

import Control.Applicative (optional)
import Control.Lens hiding ((.=))
import Data.Aeson
import Data.Aeson.Lens
import qualified Data.ByteString.Internal as BS
import qualified Data.ByteString.Lazy.Internal as LazyBS
import Data.List.NonEmpty (NonEmpty (..))
import qualified Data.List.NonEmpty as NonEmpty
import Data.Maybe
import Data.Ord
import Data.Sort
import qualified Data.Text as Text
import Data.Text (Text)
import GHC.Generics
import Network.Wreq
import qualified Options.Applicative as Opt
import Options.Applicative ((<**>))
import Text.Parsec hiding (optional)
import Text.Parsec.Char
import Text.Parsec.Text

data DevtoArticle = DevtoArticle
  { title :: Text,
    published :: Bool,
    main_image :: Text,
    canonical_url :: Text,
    tags :: Maybe (NonEmpty Text),
    series :: Maybe Text,
    body_markdown :: Text
  }
  deriving (Show, Generic, ToJSON)

eitherToMaybe :: Either e a -> Maybe a
eitherToMaybe (Right a) = Just a
eitherToMaybe _ = Nothing

stripTitleAndFirstImage :: Parser Text
stripTitleAndFirstImage = do
  _ <- spaces
  _ <- manyTill anyChar $ try newline
  _ <- spaces
  before <- manyTill anyChar $ try $ string "!["
  _ <- manyTill anyChar $ try $ char ')'
  Text.pack . (before <>) <$> many anyChar

parseTags :: Text -> [Text]
parseTags =
  take 4 . filter (not . Text.null) . fmap Text.strip . Text.splitOn ","

collectedToDev :: Config -> CollectedArticle -> Either ParseError DevtoArticle
collectedToDev Config {..} (title, body, _, url, image, _) =
  DevtoArticle title optPublished image url tags' optSeries . Text.strip
    <$> parse stripTitleAndFirstImage "" body
  where
    tags' = NonEmpty.nonEmpty =<< parseTags <$> optTags

sixth :: (a, b, c, d, e, f) -> f
sixth (_, _, _, _, _, f) = f

processPosts :: Config -> Response LazyBS.ByteString -> [DevtoArticle]
processPosts config =
  mapMaybe eitherToMaybe . fmap (collectedToDev config) . findNoteToPublish . extract
  where
    findNoteToPublish = case optNote config of
      Just note -> filter ((note ==) . sixth)
      Nothing -> take 1

type CollectedArticle =
  ( Text, -- title
    Text, -- body
    Text, -- visibility ("public" | "private")
    Text, -- url
    Text, -- poster (picture)
    Text -- path (ie. slug)
  )

extract :: Response LazyBS.ByteString -> [CollectedArticle]
extract r =
  let Fold article =
        (,,,,,) <$> Fold (key "title" . _String)
          <*> Fold (key "body" . _String)
          <*> Fold (key "visibility" . _String)
          <*> Fold (key "url" . _String)
          <*> Fold (key "poster" . _String)
          <*> Fold (key "path" . _String)
   in r ^.. responseBody . values . article

getCollectedArticles :: Config -> IO (Response LazyBS.ByteString)
getCollectedArticles Config {..} =
  getWith reqConfg url
  where
    -- curl -H "Authorization: your@email.com your-secret-token" \
    --   -H "Accept: application/json" \
    --   -H "Content-Type: application/json" \
    --   https://collectednotes.com/sites/1/notes
    reqConfg =
      defaults
        & header "Authorization" .~ [email <> " " <> collectednotesToken]
        & header "Content-Type" .~ ["application/json"]
        & header "Accept" .~ ["application/json"]
    url = "https://collectednotes.com/sites/" <> siteId <> "/notes"

postDevtoArticle :: Config -> DevtoArticle -> IO ()
postDevtoArticle Config {..} article = do
  putStrLn $ Text.unpack $ "Posting: " <> title article
  r <- postWith reqConfg url body
  putStrLn $ Text.unpack $ successMsg r
  where
    -- curl -X POST -H "Content-Type: application/json" \
    --   -H "api-key: API_KEY" \
    --   -d '{"article":{"title":"Title","body_markdown":"Body","published":true,"tags":["discuss", "javascript"]}}' \
    --   https://dev.to/api/articles
    reqConfg =
      defaults
        & header "api-key" .~ [devtoApiKey]
        & header "Content-Type" .~ ["application/json"]
        & header "Accept" .~ ["application/json"]
    url = "https://dev.to/api/articles"
    body = object ["article" .= article]
    successMsg r =
      "✓ dev.to post created: ("
        <> fromMaybe "<no response body>" (r ^? responseBody . key "url" . _String)
        <> ")\n"

data Config = Config
  { siteId :: String,
    email :: BS.ByteString,
    collectednotesToken :: BS.ByteString,
    devtoApiKey :: BS.ByteString,
    optPublished :: Bool,
    optTags :: Maybe Text,
    optSeries :: Maybe Text,
    optNote :: Maybe Text
  }
  deriving (Show)

configP :: Opt.Parser Config
configP =
  Config
    <$> Opt.strOption
      ( Opt.long "site-id"
          <> Opt.metavar "SITE_ID"
          <> Opt.help "CollectedNotes notes site ID"
      )
    <*> Opt.strOption
      ( Opt.long "email"
          <> Opt.metavar "EMAIL"
          <> Opt.help "Your CollectedNotes email"
      )
    <*> Opt.strOption
      ( Opt.long "token"
          <> Opt.metavar "TOKEN"
          <> Opt.help "CollectedNotes API Token"
      )
    <*> Opt.strOption
      ( Opt.long "api-key"
          <> Opt.metavar "API_KEY"
          <> Opt.help "dev.to API Key"
      )
    <*> Opt.switch
      ( Opt.long "publish"
          <> Opt.help "Publish the article (creates as a draft by default)"
          <> Opt.showDefault
      )
    <*> optional
      ( Opt.strOption
          ( Opt.long "tags"
              <> Opt.metavar "TAGS"
              <> Opt.help "Comma separated list of tags (max 4)"
          )
      )
    <*> optional
      ( Opt.strOption
          ( Opt.long "series"
              <> Opt.metavar "SERIES"
              <> Opt.help "dev.to article series"
          )
      )
    <*> optional
      ( Opt.strOption
          ( Opt.long "note"
              <> Opt.metavar "NOTE_SLUG"
              <> Opt.help "The path of the note to publish (collectednotes.com/my-site/<NOTE_SLUG>). If missing the latest note will be published"
          )
      )

opts :: Opt.ParserInfo Config
opts =
  Opt.info
    (configP <**> Opt.helper)
    ( Opt.fullDesc
        <> Opt.header "Post a note from CollectedNotes to dev.to"
    )

main :: IO ()
main = do
  config <- Opt.execParser opts
  r <- getCollectedArticles config
  processPosts config r
    & ( \case
          [a] -> postDevtoArticle config a
          [] -> putStrLn "404: Note not found"
          _ -> putStrLn "500: Found more than one note"
      )
```

---

**Happy and safe coding!** 🦄

Last week I migrated all my articles from dev.to. I wrote a Haskell script to do that (duh!)

Although I'm posting in Col...

Crossposting to dev.to

# TypeScript Short links

![typescript playground](https://photos.collectednotes.com/photos/63/bb3f4bba-5657-462b-ba19-8bacd1f1a21d)

If you know or use TypeScript you ought to be familiar with its [Playground](https://www.typescriptlang.org/play/). It is an awesome tool, being able to play around with TypeScript on the browser, try things out. Is also great for collaboration, since the editor's state (code and config) is kept serialized in the URL, all it take is `ctrl + s` (or `Cmd` if you are in need Mac) and the link is on the clipboard and ready to be shared.

But then you paste the link on Slack and it is looonger than the *yarn.lock* of a React application 😰

A fairly short snippet results in something like this: https://www.typescriptlang.org/play/index.html#code/PTAEBUE8AcFMGUDGAnAltALqayD2A3VAE1gGdQBHAV1UQGsBaAM1QA9RlZFcBbH2AHZEAhhlS4B5JrmQBYAFAhQ3PhNDDEiYoIykANKAwALWJFCkjuAO6gq0UKgGhIuKslCwiqDDNAAjYVJPBSU1ThV+IVFxSQA6BRCwADFfWFZhHmgAG1gIGAQUdCxEYSccAm1KGnpmNjJE0Gl3DBhcckdnV2b80gAuBPluSSxYKhzkUgA5Kh4-WHcAXlAAJliAdgBGAA5lre3dgBYFUfGpmbnkWJ94DGRSgHMACgBKAG4G0E+v74A9AH0AYCfqAGOZYDlEFhjKhyD4wbljLksqh7kYsH4aFkiANEFlAuQAKLpTI5ADCeNI5AA3gpPvxjLgiC9QDT5N9oaRYgJcBgACJcPGcIigJYbAAM7zZoAAvgppUA

That's a big nope from your coworkers who hate long links *polluting* the Slack history. And if you are anything like me you don't even like to be the one sharing long links either.

## What if ... ?

What if those long links looked like this instead?

[tsplay.dev/vwj58W](https://tsplay.dev/vwj58W)

[tsplay.dev/hello](https://tsplay.dev/hello)

## Yet another link shortener

Yes there are already a ton of link shorteners out there. But it is great to have a dedicate one. It creates identity. When you see [tsplay.dev](https://tsplay.dev) you know it'll be some TypeScript code.

🛡️ It is also about security. You never know where _tinyurl.com_ or _bit.ly_ short-links could redirect to.

## In the making

For now short links can only be created on [tsplay.dev](https://tsplay.dev).

But we are working on a [playground plugin](https://www.staging-typescript.org/dev/playground-plugins/) to create short links right there in the playground. Which should be available when the [new version of the TypeScript website](https://www.staging-typescript.org) is fully released.

---

By [Nahuel](https://dvnahuel.website/) 🎨 [Joni](https://jonidelv.me/) 💻 & myself 💻

typescript playground

If you know or use TypeScript you ought to be familiar with its Playground. It is an awesome tool,...

TypeScript Short links

# ZuricHac 2020

![alt](https://photos.collectednotes.com/photos/63/d2f52018-3a62-4592-8339-70f0ce363f50)

Last weekend I participated in [ZuricHac](https://zfoh.ch/zurihac2020/). It was an **awesome event**. Well organized 👏🙇 and full of interesting people!

> ZuriHac is the biggest [Haskell](https://www.haskell.org/) Hackathon in the world: a completely free, three-day grassroots coding festival organized by [Zürich Friends of Haskell](https://zfoh.ch/). It features fantastic keynotes, interesting tracks, and of course lots of hacking and socializing!

This year, due to Corona 🦠😷 the event took place online. Everything revolved around a [Discord](https://discord.com/) server. There were channels for particular projects people were hacking on, channels for the different tracks (beginner, intermediate and expert) and common channels to discuss the talks, hang out and share pictures of coffee ☕

Here's a small recap of the things I did and learned.

## did

- Joined 3 talks
  - [Languages all the way down](https://www.youtube.com/watch?v=kCpQ4aTzlis) by [@rob_rix](https://twitter.com/rob_rix)
  - [(Programming Languages) in Agda = Programming (Languages in Agda)](https://www.youtube.com/watch?v=x0R5h190Yts) by Philip Wadler
  - [Effects for Less](https://www.youtube.com/watch?v=0jI-AlWEwYI) by [@lexi_lambda](https://twitter.com/lexi_lambda) 🤯
- Joined one live coding session on GHC language extensions. [Write a GHC extension in 30 minutes](https://www.youtube.com/watch?v=bhhE2DxbrJM) by [@RaeHaskell](https://twitter.com/RaeHaskell).
- Joined one spontaneous call about lazy IO pintfalls when working with files by [@me_coot](https://twitter.com/me_coot).
- Found some fellow Spanish speakers _#lakeside-spanish_ (Spain, Argentina, Mexico, Guatemala, probably more!) 🇬🇹🇲🇽🇪🇸🇦🇷
- Collaborated on [tsearch.io](https://tsearch.io) and even got a contributor!!! 🤩
- Participated in different conversations and reacted with tons of emoji 🥳

## learned

- Lazy evaluation / lazy IO one of Haskell main features. As much as it enables some good stuff it can also cause some problems. When reading files (`readFile :: String -> IO String`), the files are open but not read until the evaluation is forced which might result in too many open files issues. Since files are closed as soon as the content is read the solution is to force the evaluation. 🤕
- Effect systems are all about abstraction of effects and being able to represent those effects in different ways.
- Effect systems have performance penalties due to polymorphism.
- The compiler (GHC) does a mind-blowing job optimizing code. 🤯
- To there's some much the compiler can do. So is up to the developers to find ways to produce more optimized code.
- Is important to know how and why the compiler optimizes (or not) certain code.
- TypeScript is harder than Haskell. Being able to type JavaScript programs makes for a very complex type system.
- Formal proof languages like Agda are less scary than they seem! 🤓

---

*And a huge thanks to the organizers and everyone who made the event possible!*

*I look forward to participate next year in person.*

alt

Last weekend I participated in ZuricHac. It was an awesome event. Well organized 👏🙇 and full of interesting people!



Zu...

ZuricHac 2020

# From dev.to to Collected Notes

![Collected Notes, so hot right now](https://i.imgflip.com/44o4l5.jpg)

I have been publishing notes an articles on [dev.to](https://dev.to) for around a year and a half already. Although it's a great platform and there's a pretty nice community around it, I always wanted to have my own thing. Something simpler, just upload my content and that's it. No likes, no feeds, no related posts from other users. So I got very excited when [@esacrosa](https://twitter.com/esacrosa/) announced Collected Notes and I was able to try out the alpha version 🎉

From now on I'll writing here on Collected Notes. And cross-post to [dev.to](https://dev.to) most probably.

If I'll be writing here then I should have the rest of articles and notes from [dev.to/gillchristian](htts://dev.to/gillchristian) here as well.

Inspired by [@RiccardoOdone](https://twitter.com/RiccardoOdone) videos on [scripting](https://youtu.be/XsgixFYo_Sc) [with Haskell](https://youtu.be/PU9Gs-XRYEQ) and becase  both [dev.to](https://dev.to) and Collected Notes have APIs I did what anybody would do, write some code to automate the process.

![xkcd #974](https://imgs.xkcd.com/comics/the_general_problem.png)

*\* Disclaimer, in my case it won't save time in the long run since it is a one time script.*

## The script

I won't go into detail of how the script is implemented but I do think it is worth pointing out the libraries and tools involved:

- [Stack script interpreter](https://docs.haskellstack.org/en/stable/GUIDE/#script-interpreter) allows to use Haskell for scripting, even to use libraries and a particular compiler version if needed
- [optparse-applicative](https://hackage.haskell.org/package/optparse-applicative) a command line options parsing with an applicative flavor 🌯
- [wreq](https://hackage.haskell.org/package/wreq) for HTTP requests
- [lens](http://hackage.haskell.org/package/lens), [aeson](http://hackage.haskell.org/package/aeson) & [lens-aeson](http://hackage.haskell.org/package/lens-aeson) for manipulating JSON data. It's the first time I use lenses so no idea what I was doing 🐶
- [parsec](https://hackage.haskell.org/package/parsec), a parser combinator library, which I used to parse the markdown and remove the Front Matter (metadata) section

👇 *The help text produced by optparse-applicative*

```
$ ./dev-to-collected.hs --help
Script to migrate all your dev.to articles to CollectedNotes

Usage: dev-to-collected.hs --email EMAIL --token TOKEN --api-key API_KEY

Available options:
  --email EMAIL            Your CollectedNotes email
  --token TOKEN            CollectedNotes API Token
  --api-key API_KEY        dev.to API Key
  -h,--help                Show this help text
```

`dev-to-collected.hs` ([see on GitHub](https://github.com/gillchristian/scripts.hs/blob/master/dev-to-collected.hs))

```hs
#!/usr/bin/env stack
{- stack
   script
   --resolver lts-13.27
   --package aeson
   --package sort
   --package lens-aeson
   --package wreq
   --package lens
   --package text
   --package bytestring
   --package parsec
   --package optparse-applicative
-}

{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE RecordWildCards #-}

import Control.Lens hiding ((.=))
import Data.Aeson
import Data.Aeson.Lens
import qualified Data.ByteString.Internal as BS
import qualified Data.ByteString.Lazy.Internal as LazyBS
import Data.Maybe
import Data.Ord
import Data.Sort
import qualified Data.Text as Text
import Data.Text (Text)
import Network.Wreq
import qualified Options.Applicative as Opt
import Options.Applicative ((<**>))
import Text.Parsec
import Text.Parsec.Char
import Text.Parsec.Text

type DevtoArticle =
  ( Text, -- title
    Text, -- published
    Text, -- cover_image
    Text, -- url
    Text -- body
  )

eitherToMaybe :: Either e a -> Maybe a
eitherToMaybe (Right a) = Just a
eitherToMaybe _ = Nothing

stripMeta :: Parser Text
stripMeta = do
  _ <- spaces
  _ <- string "--"
  _ <- spaces
  _ <- manyTill anyChar $ try $ string "---"
  _ <- spaces
  Text.pack <$> many anyChar

devtoToCollected :: DevtoArticle -> Either ParseError (Text, Text)
devtoToCollected (title, _, cover_image, url, body_markdown) =
  makeArticle <$> parse stripMeta "" body_markdown
  where
    makeArticle body =
      ( title,
        Text.unlines
          [ "# " <> title <> "\n",
            "*Originally posted on [dev.to/gillchristian](" <> url <> ")*.\n",
            "![" <> title <> "](" <> cover_image <> ")\n",
            body
          ]
      )

extract :: Response LazyBS.ByteString -> [DevtoArticle]
extract r =
  let Fold article =
        (,,,,) <$> Fold (key "title" . _String)
          <*> Fold (key "published_at" . _String)
          <*> Fold (key "cover_image" . _String)
          <*> Fold (key "url" . _String)
          <*> Fold (key "body_markdown" . _String)
   in r ^.. responseBody . values . article

snd5 :: (a, b, c, d, e) -> b
snd5 (_, b, _, _, _) = b

processPosts :: Response LazyBS.ByteString -> [(Text, Text)]
processPosts = mapMaybe eitherToMaybe . fmap devtoToCollected . sortOn snd5 . extract

getDevtoArticles :: Config -> IO (Response LazyBS.ByteString)
getDevtoArticles Config {..} =
  getWith reqConfg url
  where
    -- curl -H "api-key: API_KEY" https://dev.to/api/articles/me/published
    url = "https://dev.to/api/articles/me/published"
    reqConfg = defaults & header "api-key" .~ [devtoApiKey]

postCollectedArticle :: Config -> (Text, Text) -> IO ()
postCollectedArticle Config {..} (title, postBody) = do
  putStrLn $ Text.unpack $ "Posting: " <> title
  r <- postWith reqConfg url body
  putStrLn $ Text.unpack $ successMsg r
  where
    -- curl -H "Authorization: your@email.com your-secret-token" \
    -- -H "Accept: application/json" \
    -- -H "Content-Type: application/json" \
    -- https://collectednotes.com/sites/1/notes \
    -- -d '{"note": {"body": "# My new note title\nThis is the body", "visibility": "private"}}'
    reqConfg =
      defaults
        & header "Authorization" .~ [email <> " " <> collectednotesToken]
        & header "Content-Type" .~ ["application/json"]
        & header "Accept" .~ ["application/json"]
    url = "https://collectednotes.com/sites/57/notes"
    body = object ["note" .= object ["body" .= postBody, "visibility" .= ("private" :: Text)]]
    successMsg r =
      "✓ Note created: ("
        <> fromMaybe "<no response body>" (r ^? responseBody . key "url" . _String)
        <> ")\n"

data Config = Config
  { email :: BS.ByteString,
    collectednotesToken :: BS.ByteString,
    devtoApiKey :: BS.ByteString
  }
  deriving (Show)

configP :: Opt.Parser Config
configP =
  Config
    <$> Opt.strOption
      ( Opt.long "email"
          <> Opt.metavar "EMAIL"
          <> Opt.help "Your CollectedNotes email"
      )
    <*> Opt.strOption
      ( Opt.long "token"
          <> Opt.metavar "TOKEN"
          <> Opt.help "CollectedNotes API Token"
      )
    <*> Opt.strOption
      ( Opt.long "api-key"
          <> Opt.metavar "API_KEY"
          <> Opt.help "dev.to API Key"
      )

opts :: Opt.ParserInfo Config
opts =
  Opt.info
    (configP <**> Opt.helper)
    ( Opt.fullDesc
        <> Opt.header "Script to migrate all your dev.to articles to CollectedNotes"
    )

main :: IO ()
main = do
  config <- Opt.execParser opts
  r <- getDevtoArticles config
  mapM_ (postCollectedArticle config) $ processPosts r
  putStrLn "Great success!!! 🎉"
```

Is it an overkill? No doubt.

Did I learn new and cool stuff in the process? No doubt 🤓

---

**Happy and safe coding!** 🖖

Collected Notes, so hot right now

I have been publishing notes an articles on dev.to for around a year and a hal...

From dev.to to Collected Notes

# Apply me both lists

*Originally posted on [dev.to/gillchristian](https://dev.to/gillchristian/apply-me-both-lists-2kkm)*.

![Apply me both lists](https://res.cloudinary.com/practicaldev/image/fetch/s--ccl23pq1--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/jxrxbwhhiu3nuynzwblp.jpg)

As we saw in the previous one, Applicative allows to apply *n-ary* functions in a context. The context might be a parser, values that are potentially be errors, a list or a tree, optional values, IO actions, etc.

In my short learning experience so far, I've used it in practice for two things mostly.

Constructing values with data constructors that take several values. For example, those values would come from sequential parsers when working with parser combinators (like [Parsec](https://hackage.haskell.org/package/parsec)).

```hs
data User = User String String Int

-- "John Doe 26" -> User "John" "Doe" 26
parseUser :: Parser User
parseUser =
  User <$> (parseWord <* whitespace)
       <*> (parseWord <* whitespace)
       <*> parseAge

parseWord :: Parser String
parseAge :: Parser Int

whitespace :: Parser () -- consumes as much whitespace as possible

-- Defined in Control.Applicative
(<*) :: Applicative f => f a -> f b -> f a
```

`(<*)` is the lifted version of `const`, [here](https://dev.to/gillchristian/lifting-const-1a3l) is something I wrote about that. As we can guess from the signature, in this case it applies both parses (ie. both consume input) but returns the first one, ignoring the second.

And the other use case, applying *n-ary* functions to values that might not be there. In other words, when the context is Either or Maybe.

```hs
add <$> (Just 1) <*> (Just 2) -- Just 3
add <$> Nothing  <*> (Just 2) -- Nothing
add <$> (Just 1) <*> Nothing  -- Nothing
add <$> Nothing  <*> Nothing  -- Nothing

add <$> (Right 1)      <*> (Right 2)      -- Right 3
add <$> (Left "err 1") <*> (Right 2)      -- Left "err 1"
add <$> (Right 1)      <*> (Left "err 2") -- Left "err 2"
add <$> (Left "err 1") <*> (Left "err 2") -- Left "err 1"
```

### Lists

Until last week I hadn't found a use case for Applicative when working with lists. I knew how it works but never had ~~an excuse~~ a reason to use it.

Let's take a look at the instance and some examples first.

```hs
(<*>) :: Applicative f => f (a -> b) -> f a -> f b

-- With [] applied to f (using TypeApplications extension)
(<*>) @[] :: [a -> b] -> [a] -> [b]

(+) <$> [1, 2, 3] <*> [1, 2, 3]
-- [2,3,4,3,4,5,4,5,6]

(,) <$> [1, 2, 3] <*> [1, 2, 3]
-- [(1,1),(1,2),(1,3),(2,1),(2,2),(2,3),(3,1),(3,2),(3,3)]

[(++ "!"), (++ "?")] <*> ["Hola", "Mundo"]
-- ["Hola!","Mundo!","Hola?","Mundo?"]
```

As we can see, it takes a list of functions (`[a -> b]`) and a list values (`[a]`) and applies all the functions from the first list to all the values from the second one, this results in a larger list (duh!). If list sizes are `n` and `m`, respectively, the size of the returned list is `n * m`.

That's not a use case that I find very often. Most of the time I have one function (`a -> b`) that I want to apply to a list of values (`[a]`). That's Functor's `fmap` (as well as `(<$>)`). Or I have a list of functions to apply to a single value. For example, it could be list of predicates and I want to check if all or some are `True` for a particular value.

```hs
allPass :: [a -> Bool] -> a -> Bool

anyPass :: [a -> Bool] -> a -> Bool
```

By the way, there are similar functions [defined in Base](https://hackage.haskell.org/package/base-4.12.0.0/docs/GHC-List.html#v:and):

```hs
and :: [Bool] -> Bool -- True when all are True

or :: [Bool] -> Bool  -- True when at least one is True
```

In the case of lists, what applicative does is apply all the functions too all the values.

Last week, playing around on small side project, [till](https://github.com/gillchristian/till). I was trying to add the option to match several patterns against the same value and I found a use case for List's Applicative.

There's a `match` function that checks if a pattern matches a single line of the output.

```hs
match :: Pattern -> Line -> Bool
```

The output consists of a list of lines. When working with a single pattern, the solution is easy. Use [any](https://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html#v:any) (from Base).

```hs
any :: Foldable t => (a -> Bool) -> t a -> Bool

any @[] :: (a -> Bool) -> [a] -> Bool

matchPattern :: Pattern -> [Line] -> Bool
matchPattern p lns = any (match p) lns
```

What about matching several patterns against the output?

```hs
matchAll :: [Pattern] -> [Line] -> Bool
matchAll ps lns = undefined -- ???
```

Applicative to the rescue 🎉

```hs
matchAll :: [Pattern] -> [Line] -> Bool
matchAll ps lns = or (match <$> ps <*> lns)
```

Let's dissect that :mag:

```hs
-- So we don't forget ;)
(<$>) @[] :: (a -> b) -> [a] -> [b]
   
(<*>) @[] :: [a -> b] -> [a] -> [b]

-- ^ notice the difference between <$> & <*> ;)

or :: [Bool] -> Bool

match :: Pattern -> Line -> Bool

-- the input
ps :: [Pattern]

lns :: [Line]

-- mapping first to partially apply the patterns to match
match <$> ps :: [Line -> Bool]

-- applying the lines
match <$> ps <*> lns :: [Bool]

-- reducing that to get our result
or (match <$> ps <*> lns) :: Bool
```

I like how elegant this looks thanks to Functor and Applicative 🎩

NOTE: I'm sure there are other ways to solve the problem, with better performance. Although in my use case both lists *should* be relatively short, usually between one and three patterns and around 100 or probably less lines of output.

**Happy and safe coding** 🦄


Originally posted on dev.to/gillchristian.



As we saw in the previous one, Applicative allows to appl...

Apply me both lists

# Why Applicative?

*Originally posted on [dev.to/gillchristian](https://dev.to/gillchristian/why-applicative-kao)*.

![Why Applicative?](https://res.cloudinary.com/practicaldev/image/fetch/s--8ADrijl8--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/437cejvu71qhohri95x8.jpg)

When learning about the different type classes in Haskell the one I struggled the most with was, by far, [Applicative](https://en.wikipedia.org/wiki/Applicative_functor).

### Functor

[Functor](https://en.wikipedia.org/wiki/Functor) is, at least to some extent, straightforward. We take any *unary* functions and make them work on some (functor) context.

```hs
fmap :: Functor f => (a -> b) -> f a -> f b

-- or the infix version
(<$>) :: Functor f => (a -> b) -> f a -> f b
```

Say we have an increment function that works on `Int`s.

```hs
inc :: Int -> Int
```

```
λ> inc 1
2
```

By using `fmap` we can map any functor that contains an `Int`.

```
λ> fmap inc [1, 2, 3]
[2, 3, 4]
λ> fmap inc (Just 1)
Just 2
λ> fmap inc (Right 1)
Right 2
```

That becomes very clear when we align `fmap` with the function application operator.

```hs
($) ::                (a -> b) ->   a ->   b
(<$>) :: Functor f => (a -> b) -> f a -> f b

inc  $   1       --  2
inc <$> [1]      -- [2]
inc <$> (Just 1) -- Just 2
```

*fmap is just function application inside a context.*

*By the way, we'll use the infix version from now*.

### Applicative

In the case of applicative it's not clear. Or at least it took longer to click for me.

```hs
(<*>) :: Applicative f => f (a -> b) -> f a -> f b
```

Comparing with `($)` doesn't really help. Why would I want to also have the function in the context?

```hs
($) ::                      (a -> b) ->   a ->   b
(<*>) :: Applicative f => f (a -> b) -> f a -> f b
```

We said functors allow to apply a *unary* function in a context. But what happens if I want to apply a function with a higher arity?

```hs
add :: Int -> Int -> Int

add <$> (Just 1) -- ??
```

What does the repl says? 🦊

```
λ> :t add <$> (Just 1)
add <$> (Just 1) :: Maybe (Int -> Int)
```

`Maybe (Int -> Int)`? Yes, we saw that already in the `(<*>)` signature.

```hs
add <$> (Just 1) <*> (Just 2) -- Just 3
```

Let's dissect that 🔍

```hs
-- refresh these ones first :)
(<$>) :: Functor  => (a -> b) -> f a -> f b
(<*>) :: Applicative f => f (a -> b) -> f a -> f b

-- With Maybe applied (using TypeApplications extension)

(<$>) @Maybe :: (a -> b) -> Maybe a -> Maybe b

add :: Int -> Int -> Int

-- With Int applied in place of 'a'
(<$>) @Maybe @Int :: (Int -> b) -> Maybe Int -> Maybe b

-- With (Int -> Int) applied in place of 'b'
(<$>) @Maybe @Int @(Int -> Int)
--   (a   -> b)          -> Maybe a   -> Maybe b
  :: (Int -> Int -> Int) -> Maybe Int -> Maybe (Int -> Int)

add <$> (Just 1) :: Maybe (Int -> Int)
```

Here we see the first interesting thing. Since our `add` function takes two arguments (or to be more accurate one at a time). But we only provide one (the `Int` from `Maybe Int`), so it gets partially applied and returns a function (`Int -> Int`). So `b` is `Int -> Int`.

```hs
--     a  ->   b 
add :: Int -> (Int -> Int)
```

*Note that parens aren't actually needed since the arrow (`->`) is right associative.*

That was the first part of the expression. We are missing the applicative.

```hs
(<*>) @Maybe :: Maybe (c -> d) -> Maybe c -> Maybe d

-- With Int in place of 'c'
(<*>) @Maybe @Int :: Maybe (Int -> b) -> Maybe Int -> Maybe b

-- And also Int in place of 'd'
(<*>) @Maybe @Int @Int
  :: Maybe (Int -> Int) -> Maybe Int -> Maybe Int
```

*Et voilà*

```hs
add :: Int -> Int -> Int
add <$> (Just 1) :: Maybe (Int -> Int)
add <$> (Just 1) <*> (Just 2) :: Maybe  Int
```

**Functor**: apply *unary* functions in a context.

**Applicative**: apply *n-ary* functions in a context.

*This is referred as [lift](https://hackage.haskell.org/package/base-4.12.0.0/docs/Control-Applicative.html#v:liftA2) in Haskell.*

And the whole point of applying functions in such contexts is the semantics associated with them. It might be for validation, optional values (without `null` 😏), lists or trees of items, running IO actions, parsers.

When the context is Maybe:

```
λ> add <$> (Just 1) <*> (Just 2)
Just 3
λ> add <$> Nothing <*> (Just 2)
Nothing
λ> add <$> (Just 1) <*> Nothing
Nothing
λ> add <$> Nothing <*> Nothing
Nothing
```

When the context is Either:

```
λ> add <$> (Right 1) <*> (Right 2)
Right 3
λ> add <$> (Left "err 1") <*> (Right 2)
Left "err 1"
λ> add <$> (Right 1) <*> (Left "err 2")
Left "err 2"
λ> add <$> (Left "err 1") <*> (Left "err 2")
Left "err 1"
```

When the context is List:

```
λ> add <$> [1, 2, 3] <*> [1, 2, 3]
[2,3,4,3,4,5,4,5,6]
λ> (,) <$> [1, 2, 3] <*> [1, 2, 3]
[(1,1),(1,2),(1,3),(2,1),(2,2),(2,3),(3,1),(3,2),(3,3)]
```

☝️ *More on that on the next one*.

### Conclusion

When learning functional programming all these type classes might seem scary. Developing a basic intuition of their purpose and usages is a big part of the process of getting comfortable using (and understanding) them.

I know there are more implications around Functor and Applicative that I have yet to discover. But as any learning process, it takes time. I'm sure more things will become clear and start sink in as I keep going.

But that's all for today. 

**Happy and safe coding** 🎉


Originally posted on dev.to/gillchristian.



When learning about the different type classes in Haskell the o...

Why Applicative?

# Enough fp-ts to work with io-ts

*Originally posted on [dev.to/gillchristian](https://dev.to/gillchristian/enough-fp-ts-to-work-with-io-ts-20ip)*.

![Enough fp-ts to work with io-ts](https://res.cloudinary.com/practicaldev/image/fetch/s--2tU9Hejn--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/yufd1tdiyyngyr6hhzz0.jpg)

This is a small tutorial of what one needs to know about [fp-ts](https://github.com/gcanti/fp-ts) to work with [io-ts](https://github.com/gcanti/io-ts). In other words:

> Just enough fp-ts to ~~to work with io-ts~~ be dangerous

## what-ts now ?

Let's start by introducing these two libraries and what they are.

**fp-ts**

> Typed functional programming in TypeScript
>
> ... a library containing implementations of common algebraic types in TypeScript

That seems to be clear. Ok, maybe not the [algebraic types](https://en.wikipedia.org/wiki/Algebraic_data_type) but that's not super important in practice.

**io-ts**

> Runtime type system for IO decoding/encoding

Urhg, what?!

io-ts provides safe encoding/decoding. We can say is the proper way to do `JSON.parse` with types in mind. Check the library docs to learn more about it.

## But why?

io-ts is part of the [ecosystem of typed functional programming (FP) in TypeScript](https://gcanti.github.io/fp-ts/introduction/ecosystem.html), fp-ts being the main library. So naturally io-ts does good use of fp-ts.

If you are familiar with (typed) FP, then why are you still reading? Or maybe you can finish and suggest some improvements to this post 😅

On the other hand, if you aren't familiar with (typed) FP and see the [fp-ts website](https://gcanti.github.io/fp-ts/) it might seem scary and feel like a lot of information to process. Specially the weird words. Well it is a bit scary, I agree with you. But for working with io-ts we need just a really ~~small~~ smol fraction of the library. Besides that, my advice is to approach it as you would approach any other API of a library you learning to use. I'm not gonna go full *advocate of FP* mode, just say that it's really worth to learn and a pleasure to work with.

## Either it's right or left

When decoding a type with io-ts the ~~weird~~ new thing we see is, it returns a value of type `Either<t.Errors, T>` (where `T` is the type we want to decode to).

```ts
import * as t from 'io-ts'

const result: Either<t.Errors, number> = t.number.decode(123)
```

Either is an algebraic type, in particular a [discriminated union](https://www.typescriptlang.org/docs/handbook/advanced-types.html#discriminated-unions) with two branches, `Right` and `Left`. The first is usually used to denote success and the later to denote failure. In our example `t.Errors` is the type wrapped by Left and `number` is wrapped by Right. Either is a [sum type](https://en.wikipedia.org/wiki/Tagged_union) (another term for discriminated unions) because it can be either (pun intended) Left or Right, but not both.

The purpose of Either, as you probably guessed, is to work with operations that can fail or succeed. And it provides some nice features to work with it.

### `fold`ing 📂

Although one could access the internals of an Either value to get it's contents, that's not how it's intended to work.

To get a value out of it, fp-ts provides `fold`:

```ts
declare function fold<E, A, B>(
  onLeft: (e: E) => B,
  onRight: (a: A) => B,
): (e: Either<E, A>) => B
```

As the type definition implies, it expects us to handle both cases.

There are some similarities between `fold` and `Array.reduce`, which is also a way to transform a wrapped type (`Array<A>`) into a single value (`B`).

```ts
declare function reduce<A, B>(
  f: (acc: B, current: A) => B,
  initialValue: B,
): (arr: Array<A>) => B
```

NOTE: *I changed the signature `of Array.reduce` to match the signature of Either's fold*.

We are going to use `fold` mostly as the way to consume an Either. Eg. after decoding an API response with io-ts you'll either dispatch a success action (`onRight`) or a failure one and report to Honeybadger the error (`onLeft`).

You'll see that most (if not all) of the algebraic types that fp-ts defines have their own version of `fold` 🔍

### `map`ing 🗺️

Once we have `fold` in our toolbelt we might be tempted to extract values out of Either every time we want to work with them.

What if I told you, you don't have to?

Just like `Array.map`, there's also `map` defined for Either.

```ts
// Array's map
declare function map<A, B>(f: (a: A) => B): (arr: Array<A>) => Array<B>

// Either's map
declare function map<A, B>(f: (a: A) => B): <E>(e: Either<E, A>) => Either<E, B>
```

NOTE: *I changed the signature of `Array.map` to match Either's one*.

As we can see, it allows us to transform the Right value of an Either by applying a function to its contents. If our value happens to be a Left, it won't be changed. And we can keep working happily with our wrapped value, no `fold`ing required.

What about transforming the Left value you ask? `mapLeft` to the rescue, and this time the unchanged one is the Right.

```ts
declare function mapLeft<E, G>(
  f: (e: E) => G,
): <A>(fa: Either<E, A>) => Either<G, A>
```

### Constructing Eithers 👷‍♂️

The last thing we need to know about Either is how to construct values.

```ts
import {left, right, Either} from 'fp-ts/lib/Either'

declare function left<E = never, A = never>(e: E): Either<E, A>

declare function right<E = never, A = never>(a: A): Either<E, A>

const aRight: Either<never, number> = right(123)

const aLeft: Either<string, never> = left('some error message')
```

## [Go Through The Pipes](https://www.youtube.com/watch?v=HioMxPJj59U)

Although strictly that's all we need from fp-ts to work with io-ts, we are also going to be using a few utilities it provides to work with functions. It's a FP library after all, right?

### pipe 🚿

This is one of the ways to do function composition in fp-ts. It let's us *pipe* a value through a list of functions, where the next function is called with the result of the previous one.

Take this case for example:

```ts
export const decodeWith = <A>(decoder: Decoder<unknown, A>) => (
  response: unknown,
) =>
  mapLeft((errors) => ({tag: 'decoding', errors} as const))(
    humanizeErrors(decoder.decode(response)),
  )
```

We decode a response, humanize the potential errors and then map the left to another type.

With pipe it would look like this:

```ts
import { pipe } from 'fp-ts/lib/pipeable';

export const decodeWith = <A>(decoder: Decoder<unknown, A>) => (
  response: unknown,
) =>
  pipe(
    response,
    decoder.decode,
    humanizeErrors,
    mapLeft((errors) => ({tag: 'decoding', errors} as const)),
  )
```

Now the code reads just like the description:

> decode a response, humanize the potential errors and then map the left to another type.

One good thing about pipe is, it's ready for when [the pipeline operator proposal](https://github.com/tc39/proposal-pipeline-operator) lands in JS. Sadly, judging by the pace TC39 works at, that might take years.

```diff
-import { pipe } from 'fp-ts/lib/pipeable';
-
 export const decodeWith = <A>(decoder: Decoder<unknown, A>) => (
   response: unknown,
 ) =>
-  pipe(
-    response,
-    decoder.decode,
-    humanizeErrors,
-    mapLeft((errors) => ({tag: 'decoding', errors} as const)),
-  )
+  response
+    |> decoder.decode
+    |> humanizeErrors
+    |> mapLeft(errors => ({ tag: 'decoding', errors } as const))
```

### flow ✉️

`flow` is right to left function composition. Very similar to pipe, but doesn't take the value as first argument but instead returns a function.

```diff
-import { pipe } from 'fp-ts/lib/pipeable';
+import { flow } from 'fp-ts/lib/function';
 
-export const decodeWith = <A>(decoder: Decoder<unknown, A>) => (
-  response: unknown,
-) =>
-  pipe(
+export const decodeWith = <A>(decoder: Decoder<unknown, A>) =>
+  flow(
-    response,
     decoder.decode,
     humanizeErrors,
     mapLeft((errors) => ({tag: 'decoding', errors} as const)),
   )
```

## That's it but there's more

As far as using io-ts, that's all we need to know about fp-ts (for now at least). If you are already bored, no need to keep on reading.

Although we could use fp-ts (and it's ecosystem) for many other things, this is a great start. By decoding all IO stuff (a.k.a. API responses) we make sure to remove unexpected runtime behavior and errors because we promised the compiler a `JSON.parse` returns something when in reality it doesn't.

If you see the value on it and want to learn more about (typed) FP check out the [Core Concepts](https://gcanti.github.io/fp-ts/introduction/core-concepts.html) and [Learning Resources](https://gcanti.github.io/fp-ts/introduction/learning-resources.html) sections in the fp-ts docs. And more importantly make sure to ask questions and look for other people that are in the path of learning about (typed) FP as well.

## No M word? 🌯

Somehow I managed to write about FP without using the word monad (well, now I did). That is because there was no need to do so. Even though Either is a monad, we didn't use any of it's monadic properties. We did use it as a Functor. A functor is an algebraic type that has `map` defined to it, which [has to abide some laws](https://wiki.haskell.org/Functor#Functor_Laws) to make sure every functor instance is consistent. You wouldn't want Either's map behaving differently than Array's map. Oh and yeah, Array is also a Functor.

Once again, learning these terms (monad, functor, applicative, foldable, *et al*) is not necessary. But, if you are interested, it can be really useful. For example, if you know that Array has map defined because it's a functor. And then discover a new algebraic type (like Either) that is also a functor you'll already know how to work with the map for that type.

---

Ok, now that's it.

**Happy and safe coding** 🤓


Originally posted on dev.to/gillchristian.



This is a small tutorial of what ...

Enough fp-ts to work with io-ts

# Lifting const 

*Originally posted on [dev.to/gillchristian](https://dev.to/gillchristian/lifting-const-1a3l)*.

![Lifting const ](https://res.cloudinary.com/practicaldev/image/fetch/s--YiVlidw2--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://thepracticaldev.s3.amazonaws.com/i/y9xvvsj06l36cacnoq3p.jpeg)

Yesterday I shared this gist:

[twitter https://twitter.com/gillchristian/status/1175878924926095360]

And I planned to expand on it today based on some assumptions I had:

[twitter https://twitter.com/gillchristian/status/1176126201234169860]

By playing around in GHCi I found out that my assumption was wrong.

![you are wrong meme](https://thepracticaldev.s3.amazonaws.com/i/4xth2mphqqvkptf1eir7.jpg)

So I did a bit of digging, by digging I mean [Hoogling](https://hoogle.haskell.org) the functions and checking their sources in Hackage, to understand why.

I found some interesting things.

Let's check [again](https://twitter.com/gillchristian/status/1173326782700953601?s=20) how the operator `(<*)` works.

```haskell
(<*) :: Applicative f => f a -> f b -> f a
```

As it is always the case in Haskell, the signature says a lot. It looks like it takes two applicatives and returns the first one.

```haskell
Just 1 <* Just 2 -- Just 1
```

And yes, that's right. But there's more...

It does not only return the first one discarting the second. Instead it "runs" both and returns the first one. How do we know it "runs" both? Because the semantic of such applicative (in this case Maybe) are *respected*:

```haskell
Nothing <* Just 1  -- Nothing
Just 1  <* Nothing -- Nothing
```

And that is the difference with `const`.

```haskell
Just 1  `const` Just 2  -- Just 1
Just 1  `const` Nothing -- Just 1
Nothing `const` Just 1  -- Nothing
```

When I said that `(<*)` is the "lifted" version of `const` I didn't mean *lifted* in the Haskell sence, I meant *lifted* as in the function was used in the context of an applicative. Well I guess that's kind of what *lifted* means, so let's try again. What I meant is that the signature was "the same" but in the applicative context (same semantics, always returning the first argument and discarting the second).

Turns out, `(<*)` is actually the "lifted" version of `const` (in the Haskell sense). Oh, and that's exactly the implementation in `base`.

```haskell
class Functor f => Applicative f where
    -- ...

    -- | Sequence actions, discarding the value of the second argument.
    (<*) :: f a -> f b -> f a
    (<*) = liftA2 const
```

*[See source in Hackage](https://hackage.haskell.org/package/base-4.12.0.0/docs/src/GHC.Base.html#%3C%2A)*

So what I was wrong about? 🤔

I assumed that if you *lifted* `const` it would still behave as the good ol' const.

```haskell
constA = liftA2 const

Just 1  `constA` Just 2  -- Just 1
Just 1  `constA` Nothing -- Just 1
Nothing `constA` Just 1  -- Nothing
```

Well, as we saw already, it doesn't. As I said it *respects* the semantics of the applicative.


```haskell
constA = liftA2 const

Just 1  `constA` Just 2  -- Just 1
Just 1  `constA` Nothing -- Nothing
Nothing `constA` Just 1  -- Nothing
```

Because that is the whole point of `liftA2`.

\* to be continued (whit a deeper look into `liftA2`).

*P.S. Yeah I used a "lifting" 🏋️ picture in a post about lifting. Sorry.*

Originally posted on dev.to/gillchristian.

 

Yesterday I shared this gist:

[twitter https://twitter.com/gillchr...

Lifting const

# Encoding and decoding JSON with Aeson

*Originally posted on [dev.to/gillchristian](https://dev.to/gillchristian/encoding-and-decoding-json-with-aeson-28af)*.

![Encoding and decoding JSON with Aeson](https://res.cloudinary.com/practicaldev/image/fetch/s--F3Bil8QW--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://images.pexels.com/photos/209137/pexels-photo-209137.jpeg%3Fauto%3Dcompress%26cs%3Dtinysrgb%26dpr%3D2%26h%3D750%26w%3D1260)

In the past days I've been working on a small app to parse the transactions statements I get from my bank with the idea to generate something that is easier to visualize.

I get a `.txt` file where each line corresponds to one transaction and from that I wanted to generate a JSON file that then I can use in a charting app.

In the process I learned a few things about working with JSON in Haskell using [Aeson](http://hackage.haskell.org/package/aeson-1.4.3.0/docs/Data-Aeson.html).

To decode and encode values from and to JSON we use the `decode` and `encode` methods (good naming there 😉).

```haskell
decode :: FromJSON a => ByteString -> Maybe a
encode :: ToJSON a => a -> ByteString
```
NOTE: By setting the [OverloadedStrings](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html#overloaded-strings) compiler extension we can treat string literals as not only `String` but also `ByteString`, `Text`, and others.


We can learn a lot about how Aeson works from these type signatures.

`decode` takes a `ByteString` (we can think of it as a string) and returns a `Maybe a` with the constraint that this `a` has to have the `FromJSON` type class. With that name we can assume that it's for types that can be parsed from JSON.

`encode` on the other hand takes a value of type `a`, this time with the `ToJSON` type class and returns a string. In this case we can assume `ToJSON` means a type that can be converted to JSON.

Let's then try to use them. Notice that we need to specify what type we are decoding/encoding so the compiler know what instance of FromJSON/ToJSON should use.

```
λ> :set -XOverloadedStrings
λ> import Data.Aeson
λ> decode "true" :: Maybe Bool
Just True
λ> decode "tru" :: Maybe Bool
Nothing
λ> decode "123" :: Maybe Bool
Nothing
λ> decode "123" :: Maybe Int
Just 123
λ> encode (123 :: Int)
"123"
λ> encode ("hola" :: String)
"\"hola\""
λ> encode (Just 123 :: Maybe Int)
"123"
λ> encode (Nothing :: Maybe Int)
"null"
```

Decoding returns a `Maybe a` because the operation can fail since we don't know if the JSON in the string is properly formatted. Whereas encoding, since we have the `ToJSON` constraint should always succeed.

All of those types "work out of the box" because the instances are already implemented by Aeson 🎉

```
λ> :i Int
data Int = ghc-prim-0.5.3:GHC.Types.I# ghc-prim-0.5.3:GHC.Prim.Int#
        -- Defined in ‘ghc-prim-0.5.3:GHC.Types’
...
instance ToJSON Int
  -- Defined in ‘aeson-1.4.2.0:Data.Aeson.Types.ToJSON’
instance FromJSON Int
  -- Defined in ‘aeson-1.4.2.0:Data.Aeson.Types.FromJSON’
```

But we are not going to work only with primitive types, are we?

But if we try to encode a value of a custom type we get an error.

```
λ> data Obj = Obj { id :: Int }
λ> encode Obj { id = 1 }

<interactive>:5:1: error:
    • No instance for (ToJSON Obj) arising from a use of ‘encode’
    • In the expression: encode Obj {id = 1}
      In an equation for ‘it’: it = encode Obj {id = 1}
```

We need to implement `ToJSON` for this type.

```
λ> :i ToJSON
class ToJSON a where
  toJSON :: a -> Value
  default toJSON :: (GHC.Generics.Generic a,
                     aeson-1.4.2.0:Data.Aeson.Types.ToJSON.GToJSON
                       Value Zero (GHC.Generics.Rep a)) =>
                    a -> Value
  toEncoding :: a -> Encoding
  toJSONList :: [a] -> Value
  toEncodingList :: [a] -> Encoding
        -- Defined in ‘aeson-1.4.2.0:Data.Aeson.Types.ToJSON’
```

We could do it manually:

```haskell
{-# LANGUAGE OverloadedStrings #-}

import Data.Aeson

newtype Obj = Obj
  { a :: Int
  }

instance ToJSON Obj where
  toJSON Obj {a = a} = object [("a", toJSON a)]

-- object :: [Pair] -> Value
-- type Pair = (Text, Value) -- Value here is the Aeson.Value
```

Or we can use some compiler magic to do it for us using the compiler extensions: [DeriveAnyClass](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html?highlight=deriveanyclass#extension-DeriveAnyClass) & [DeriveGeneric](https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/glasgow_exts.html?highlight=deriveanyclass#extension-DeriveGeneric).

```haskell
{-# LANGUAGE DeriveAnyClass #-}
{-# LANGUAGE DeriveGeneric  #-}
{-# LANGUAGE OverloadedStrings #-}

import Data.Aeson

newtype Obj = Obj
  { a :: Int
  } deriving (Generic, ToJSON)
``` 

*Et voilà* 🎉

That is what we'll be doing most of the time, unless we to encode or decode our data in some particular way.

Implementing and deriving `FromJSON` works pretty much the same so it's not worth to show it.

## Conclusion

The compiler magic of deriving type classes instances makes it really easy to work with JSON in Haskell. We still have the safety of our types without having to implement custom encoder/decoders for everything like other languages (e.g. Elm).


Originally posted on dev.to/gillchristian.



In the past days I've...

Encoding and decoding JSON with Aeson

# Lists

*Originally posted on [dev.to/gillchristian](https://dev.to/gillchristian/day-16-lists-3d8k)*.

![Lists](https://res.cloudinary.com/practicaldev/image/fetch/s--nZ3EXgW2--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://images.pexels.com/photos/793088/pexels-photo-793088.jpeg%3Fauto%3Dcompress%26cs%3Dtinysrgb%26dpr%3D2%26h%3D750%26w%3D1260)

> The explicit teaching of thinking is no trivial task, but who said that the teaching of programming is? In our terminology, the more explicitly thinking is taught, the more of a scientist the programmer will become.
> *Edsger Dijkstra*

More catch up ™️, this time with a previous week's session, [Delft Haskell Study Group #6](https://www.meetup.com/Delft-Haskell-Study-Group/events/260075544/). As always, I quote [the book](http://haskellbook.com/) as a way of recap 📖

## About thinking 🤔

I'm always adding the quotes the book adds at the cover of each chapter but never mention anything about them. I really liked this one in particular. Programming is all about thinking. The more we learn to think the better programmers we'll be.

## Lists

The list datatype in Haskell is defined like this:

```haskell
data [] a = [] | a : [a]
```

There are a few things to point out there. `[]` Is both the type constructor as well as the data constructor for the empty list. The other constructor (`:`), the infix operator called [*cons*](https://en.wikipedia.org/wiki/Cons), takes a value of type `a` and a list of type `[a]` and evaluates to `[a]`. The data type as a whole is a sum (`|`) but the second constructor (`:`) is a product. What `a : [a]` does is adding `a` to the front of the list.

### Pattern matching 🎉

As I already mentioned pattern matching is one of my favorite features of Haskell. And we can do quite some interesting things by pattern matching on lists.

```haskell
head' :: [a] -> Maybe a
head' []       = Nothing
head' (x : _ ) = Just x

tail' :: [a] -> Maybe [a]
tail' []       = Nothing
tail' (_ : xs) = Just xs
```

I wrote these versions that return the value wrapped in a maybe because `[a]` doesn't guarantee that the list will have values. If we try the [Prelude](http://hackage.haskell.org/package/base-4.12.0.0/docs/Prelude.html) version of these functions on empty lists we get and error.

```
λ> head []
*** Exception: Prelude.head: empty list
λ> tail []
*** Exception: Prelude.tail: empty list
```

One thing to mention about our `tail'`. In case of calling it with a list that has one value, it will return `Just []`. I think it's fine, since it reflects what the tail of a list with one element is (`a : []`). But if we'd want to only return lists with elements we could extend it like so.

```haskell
tail' :: [a] -> Maybe [a]
tail' []       = Nothing
tail' (_ : []) = Nothing
tail' (_ : xs) = Just xs
```

### Sweet sweet syntactic sugar 🍭

To write a list of four elements using the constructor we'd have to do use the cons operator 4 times.

```haskell
(1 : 2 : 3 : 4 : [])
```

Luckily Haskell provides some syntactic sugar to make it easier, which resembles the one in many other languages.

```haskell
[1, 2, 3, 4]
```

### Ranges

Another nice thing to work with lists that Haskell provides is the ranges syntax.

```
λ> [1..10]
[1,2,3,4,5,6,7,8,9,10]

λ> [2, 4..10]
[2,4,6,8,10]

λ> [1..]
[1,2,3,4,5,6,7,8,9,10,11,12 ...] -- continues infinitely


λ> [1, 5..]
[1,5,9,13,17,21,25,29,33,37,41,45 ...] -- continues infinitely
```

Which are equivalent to.

```
λ> enumFromTo 1 10
[1,2,3,4,5,6,7,8,9,10]

λ> enumFromThenTo 2 4 10
[2,4,6,8,10]

λ> enumFrom 1
[1,2,3,4,5,6,7,8,9,10,11,12 ...] -- continues infinitely


λ> enumFromThen 1 5
[1,5,9,13,17,21,25,29,33,37,41,45 ...] -- continues infinitely
```

All of these functions require the type being ranged, in other words an `Enum` type class.

```haskell
enumFromTo :: Enum a => a -> a -> [a]
enumFromThenTo :: Enum a => a -> a -> a -> [a]

enumFrom :: Enum a => a -> [a]
enumFromThen :: Enum a => a -> a -> [a]
```

## List comprehensions


> List comprehensions are a means of generating a new list from a list or lists. They come directly from the concept of set comprehensions in mathematics, including similar syntax. They must have at least one list, called the generator, that gives the input for the comprehension, that is, provides the set of items from which the new list will be constructed. They may have conditions to determine which elements are drawn from the list and/or functions applied to those elements.

Coming from a non-mathematical background (JS, PHP, C++, Go, .etc) this was one of the really new things for me.

```haskell
[ x^2 | x <- [1..10]]
```

Give the definition we can guess that we are building a list of all the square numbers from the list of `[1..10]`. Or at least I'd guess that because I already read the chapter 😂


```
λ> [ x^2 | x <- [1..10]]
[1,4,9,16,25,36,49,64,81,100]
```

We can add predicates to ignore certain items. The ones the predicate returns `False` for, naturally. For example, we can decide to keep only the numbers divisible by 3.

```
λ> [x^2 | x <- [1..10], rem x 3 == 0]
[9,36,81]
```

List comprehensions can have multiple generators.

```
λ> [x^y | x <- [1..5], y <- [2, 3]]
[1,1,4,8,9,27,16,64,25,125]

λ> [(x, y) | x <- [1..5], y <- [2, 3]]
[(1,2),(1,3),(2,2),(2,3),(3,2),(3,3),(4,2),(4,3),(5,2),(5,3)]
```

Notice that the rightmost generator is exhausted first, then the second one and so on.

### Spines and nonstrict evaluation

Lists are a recursive series of cons cells `a : [a]` terminated by the empty list `[]`. Now, it'd be great to find a way to visualize that.

In Haskell we say that some data structures (lists, sequences and trees) have a *spine*, the connective structure that ties the collection of values together. In lists it's the recursive cons (`:`) operators.

```
1 : 2 : 3 : []

or

1 : (2 : (3 : []))
```

There's a problem with this `1 : 2 : 3 : []` representation, it makes it look like `1` exists before the *cons cell* but actually it contains the two values. Looking more like the following.

```
  :
 / \
1   :
   / \
  2   :
     / \
    3  []
```

> Because of this and the way nonstrict evaluation works, you can evaluate cons cells independently of what they contain. It is possible to evaluate only the spine of the list without evaluating individual values. It is also possible to evaluate only part of the spine of a list and not the rest of it.

Evaluation of a list goes down the spine, while construction goes up. But nothing is evaluated until it is needed to be.

As we said, the spine is the recursive series of cons operators (`:`). And in here the `_` would be the non evaluated values.

```
 : <------|
/ \       |
_  : <----| This is the "spine"
  / \     |
 _   : <--|
    / \
   _  []
```

Using `:sprint` in GHCi we can see what is evaluated and what isn't.

```
λ> ls = [1..5] :: [Int]
λ> :sprint ls
ls = _

```

So, `ls` hasn't been evaluated yet (as `_` indicates).

```
λ> take 1 ls
[1]
λ> :sprint ls
ls = 1 : _
```

Now we evaluated the first cons cell and it's first value. Let's take 2 values.

```
λ> take 2 ls
[1, 2]
λ> :sprint ls
ls = 1 : 2 : _
```

We can continue like that until the end. We can also evaluate the whole spine with `length`.

```
λ> length ls
5
λ> :sprint ls
ls = [1,2,3,4,5]
```

Wait but I said the spine only 🤔 This is some quirk of GHCi. But we can prove it's only the spine by checking a list of bottom ⊥ (i.e. `undefined`).

```
λ> undefined
*** Exception: Prelude.undefined
CallStack (from HasCallStack):
  error, called at libraries/base/GHC/Err.hs:78:14 in base:GHC.Err
  undefined, called at <interactive>:1:1 in interactive:Ghci1
```

As we can see it throws an exception when evaluated. But ...

```
λ> ls = [undefined, undefined]
λ> :sprint ls
ls = _
λ> length ls
2
λ> :sprint ls
ls = [_,_]
```

As we can see Haskell only evaluates what it needs and nothing else. The book extends on this a bit more and explains the concepts of *normal form* and *weak head normal form*. But I'll get back to those in more depth in the chapter of nonstrictness.

### Transforming lists of values

We can use `map` or `fmap` to transform a list of values, by applying a function to each element and then returning the new list.

```haskell
map  ::              (a -> b) -> [a] -> [b]
fmap :: Functor f => (a -> b) -> f a -> f b
```

`fmap` is the generalized version of `map` that works for Functors. List is one of them. More on Functors in a following chapter.

```
λ> fmap (+1) [1, 2, 3, 4]
[2,3,4,5]
```

This is how it's defined in `base`.


```haskell
map :: (a -> b) -> [a] -> [b]
map _ []     = []
map f (a:as) = f a : map f as
```

By adding some parens to the type definition we can make it more explicit what map really allows us to do. Basically lifting our function `a -> b` to work in lists.

```
(a -> b) -> ([a] -> [b])

( a  ->  b )
([a] -> [b])
```

### Filtering lists of values

`map` is not the only function we can use on lists. We can also filter certain values out of a list when they don't fulfill a predicate.

```
λ> even 10
True
λ> even 9
False
λ> filter even [1..10]
[2,4,6,8,10]
```

Here's how `filter` is defined.

```haskell
filter :: (a -> Bool) -> [a] -> [a]
filter _ [] = []
filter pred (x:xs)
  | pred x    = x : filter pred xs
  | otherwise = filter pred xs
```

### Zipping lists


> Zipping lists together is a means of combining values from multiple lists into a single list.

```
λ> :t zip
zip :: [a] -> [b] -> [(a, b)]
λ> zip "abc" "cde"
[('a','c'),('b','d'),('c','e')]
λ> zip "abc" "cdefghi"
[('a','c'),('b','d'),('c','e')]
λ> zip "abcdefghi" "jkl"
[('a','j'),('b','k'),('c','l')]
```

Note that `zip` returns the length of the shortests list.

We can also `unzip` lists.

```
λ> :t unzip
unzip :: [(a, b)] -> ([a], [b])
λ> unzip [(1,'a'), (2, 'b'), (3, 'c')]
([1,2,3],"abc")
```

There's also `zipWith` to combine two lists.

```
λ> :t zipWith
zipWith :: (a -> b -> c) -> [a] -> [b] -> [c]
λ> zipWith (+) [1,2,3] [1,2,3]
[2,4,6]
λ> zipWith (+) [1,2,3] [1,2,3]
[2,4,6]
λ> zipWith (,) [1,2,3] [1,2,3]
[(1,1),(2,2),(3,3)]
```

## Conclusion

With lists we start to see the declarative patterns of functional programming. And how the same functions we can use for plain values can be used for lists as well with higher order functions like `map`, `filter` and `zip`.

Thanks to Haskell's laziness (nonstrict evaluation) it will only evaluate what it needs and no more.

```
λ> ls = [1,2,3,4,5,6,7,undefined]
λ> filter even ls
[2,4,6*** Exception: Prelude.undefined
λ> take 2 $ zip "abcdefg" $ map (*2) $ filter even ls
[('a',4),('b',8)]
```

Although it's clear in this example, it has many more implications that I'm yet to understand or even discover and I look forward to learn about that.


Originally posted on dev.to/gillchristian.





The explicit teaching of thinking is no trivial task, but who said that the teachin...

Lists

# More Functional Patterns and Recursion

*Originally posted on [dev.to/gillchristian](https://dev.to/gillchristian/day-15-more-functional-patterns-and-recursion-4mic)*.

![More Functional Patterns and Recursion](https://res.cloudinary.com/practicaldev/image/fetch/s--JPX0BEyj--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://images.pexels.com/photos/691710/pexels-photo-691710.jpeg%3Fauto%3Dcompress%26cs%3Dtinysrgb%26dpr%3D2%26h%3D750%26w%3D1260)

> I would like to be able to always...divide the things up into as many pieces as I can, each of which I understand separately. I would like to understand the way of adding things up, independently of what it is I’m adding up.
> *Gerald Sussman*

I'm playing a bit of catching up since this corresponds to previous week's session [Delft Haskell Study Group #5](https://www.meetup.com/Delft-Haskell-Study-Group/events/259979758/).

As always, I quote [the book](http://haskellbook.com/) as a way of recap.

## Functional Patterns

### Arguments and parameters

All Haskell values can be arguments to functions, even other functions. This is key in functional programming (FP). A value that can be used as an argument to a function is a *first-class* value.

**Parameters** are the variables declared in the function definition.

```haskell
add :: Num a => a -> a -> a
add a b = a + b
    ^ ^
    | |
   a & b are parameters
```

**Arguments** are the values applied to a function when calling it. The value of the argument is bound to the named parameter in our function definition.

```haskell
x :: Int
x = 1

y :: Int
y = 2

add x y
    ^ ^
    | |
   x & y ar arguments, bound to add's a & b respectively
```

Applying a function binds its parameters to values. Type parameters become bound to a type, and function variables are bound to a value.

### Pattern matching

One of Haskell's killers features ♥️ Whenever I do something in a language that supports it somehow and then go back to JS/TS I suffer a lot 😭

... is a way of matching values against patterns and, where appropriate, binding variables to successful matches. It is worth noting here that patterns can include things as diverse as undefined variables, numeric literals, and list syntax.

Pattern matching allows you to expose data and dispatch different behaviors based on that data in your function definitions by deconstructing values to expose their inner workings.

**Pattern matching values**

```haskell
isItA :: Char -> Bool
isItA 'a' = True
isItA _   = False


isIt123 :: Int -> Bool
isIt123 1 = True
isIt123 2 = True
isIt123 3 = True
isIt123 _ = False
```

The underscore acts as a wild card, it matches anything. Since it matches anything it has to be the last case, otherwise we'd never get pass it.

**Pattern matching against data constructors**

We can deconstruct data in pattern matching and match against that:

```haskell
withDefault :: a -> Maybe a -> a
withDefault _ Just a  = a
withDefault b Nothing = b

head' :: [a] -> Maybe a
head' []     = Nothing
head' (x:xs) = Just x

first :: (a, b) -> a
first    (a, b) =  a -- notice how much it looks like the signature
```

**Case expressions**

We can also pattern match in case expressions, which are similar to `switch`es from imperative languages. But, as the name suggests, they are expressions.

```haskell
withDefault :: a -> Maybe a -> a
withDefault def maybeA =
  case maybeA of
    Nothing -> b
    Just a  -> a
```

### Higher order functions (HOFs)

Functions that accept functions as arguments. As I said, this is key in FP and allows to combine functions efficiently.

```haskell
flip :: (a -> b -> c) -> b -> a -> c
flip f b a = f a b
```

`f` is a function, making `flip` a HOF.

The book gives many more examples. But really it is a simple concept that is seen all over the place in FP that it can be understood without giving much thought to it.

### Guards

Just a syntax pattern that relies on truth values to decide between two or more possible returns

```haskell
abs' :: Int -> Int
abs' x
  | x < 0 = (-x)
  | otherwise = x
```

`otherwise` is the guard's wildcard and is nothing more than `True`.

```
λ> :t otherwise
otherwise :: Bool
λ> otherwise
True
```

### Function composition

Another of the pillars of FP. Allows us to combine functions such that the result of applying one function gets passed to the next function as an argument.

Compose is defined defined as the dot (`.`) operator:

```haskell
(.) :: (b -> c) -> (a -> b) -> a -> c
(f . g) x = f (g x)
```

```
λ> :t negate
negate :: Num a => a -> a
λ> :t sum
sum :: (Foldable t, Num a) => t a -> a
λ> :t negate . sum
negate . sum :: (Num c, Foldable t) => t c -> c
λ> negate . sum $ [1, 2, 3, 4, 5]
-15
```

#### Pointfree style

Pointfree refers to a style of composing functions without specifying their arguments. The “point” in “pointfree” refers to the arguments, not (as it may seem) to the function composition operator. In some sense, we add “points” (the operator) to be able to drop points (arguments).

```
λ> f = negate . sum
λ> :t f
f :: (Num c, Foldable t) => t c -> c
λ> f [1, 2, 3, 4, 5]
-15
```

Although `f` has an argument we don't specify it.

```haskell
f :: Int -> [Int] -> Int

f z xs = foldr (+) z xs -- pointfull, all arguments specified

f = foldr (+) -- pointfree, arguments not specified
```

```
λ> f 0 [1..5]
15
```

Another example of composition:

```haskell
putStrLn :: String -> IO ()
show :: Show a => a -> String

print :: Show a => a -> IO ()
print = putStrLn . show
```

## [Recursion](https://dev.to/gillchristian/day-15-more-functional-patterns-and-recursion-4mic#recursion)

Recursion is defining a function in terms of itself via self-referential expressions. It means that the function will continue to call itself and repeat its behavior until some condition is met to return a result.

Comes from the [fixed point combinator](https://en.wikipedia.org/wiki/Fixed-point_combinator) (or Y combinator) of lambda calculus.

The classic recursion example is the factorial (`!`).

```
4! = 4 * 3 * 2 * 1
        12 * 2 * 1
            24 * 1
                24
4! = 24
```

And we can define it as a recursive function.

```haskell
brokenFactorial :: Integer -> Integer
brokenFactorial n = n * brokenFactorial (n - 1)
```

That has a problem though, it keep calling itself infinitely, or in fact until we run out of stack.

We have to define a base case.

```haskell
factorial :: Integer -> Integer
factorial 0 = 1
factorial n = n * factorial (n - 1)
```

Making our base case an identity value for the function (multiplication in this case) means that applying the function to that case doesn’t change the result of previous applications.

### Bottom

`⊥` or bottom is a term used in Haskell to refer to computations that do not successfully result in a value. The two main varieties of bottom are computations that failed with an error or those that failed to terminate (loop).

Not much more to say about bottom.

**Error**

```haskell
f :: Bool -> Int
f True = error "sarasa"
f False = 0
```

```
λ> f False
0
λ> f True
*** Exception: sarasa
CallStack (from HasCallStack):
  error, called at <interactive>:1:10 in interactive:Ghci1
```

**Loop**

```
λ> x = x in x
*** Exception: <<loop>>
```

## Conclusions

Haskell is not only a functional language but it also offers a few nice things that really make writing code very nice an expressive. I, personally, am a fan of pattern matching, functions defined as infix operators and the [polymorphism model](https://dev.to/gillchristian/day-13-types-59m6#polymorphism). I really miss those features whenever I write code in other languages that don't support them.

Also, this is when the book starts to get interesting. We'll be seeing more code from now on 🎉


Originally posted on dev.to/gillchristian.





I would like to b...

More Functional Patterns and Recursion

# Type classes

*Originally posted on [dev.to/gillchristian](https://dev.to/gillchristian/day-14-type-classes-5571)*.

![Type classes](https://res.cloudinary.com/practicaldev/image/fetch/s--83wgLdTx--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://images.pexels.com/photos/905847/pexels-photo-905847.jpeg%3Fauto%3Dcompress%26cs%3Dtinysrgb%26dpr%3D2%26h%3D750%26w%3D1260)

Here we go with another chapter of the [Haskell book](http://haskellbook.com/) from [Delft Haskell Study Group Session #4](https://www.meetup.com/Delft-Haskell-Study-Group/events/259694156/). This time it was chapter 6, about Type classes.

As always, quotes are from the book and meant as a recap.

## Type classes?

> Type classes and types in Haskell are, in a sense, opposites. Where a declaration of a type defines how that type in particular is created, a declaration of a type class defines how a set of types are *consumed* or used in computations.
>
> Type classes allow us to generalize over a set of types in order to define and execute a standard set of features for those types.

Type classes are sort of *interfaces* than can work on several types. Through type classes Haskell achieves constrained or *ad-hoc* polymorphism.

> The goal is to define a datatype by cases, where one can add new cases to the datatype and new functions over the datatype, without recompiling existing code, and while retaining static type safety (e.g., no casts). [^1]

So we have type classes as constraints or rules and we say a type implements or instantiates the type classes by, well, implementing or instantiating those constraints/rules.

This is, for example, what the `Bool` type implements.

```
λ> :i Bool
data Bool = False | True        -- Defined in ‘GHC.Types’
instance Eq Bool -- Defined in ‘GHC.Classes’
instance Ord Bool -- Defined in ‘GHC.Classes’
instance Show Bool -- Defined in ‘GHC.Show’
instance Read Bool -- Defined in ‘GHC.Read’
instance Enum Bool -- Defined in ‘GHC.Enum’
instance Bounded Bool -- Defined in ‘GHC.Enum’
```

That means that all the constraints defined for `Eq`, `Ord`, `Show`, `Read`, `Enum` and `Bounded` are available to be used with `Bool`s.

Let's take a look at `Ord`

```
λ> :i Ord
class Eq a => Ord a where
  compare :: a -> a -> Ordering
  (<) :: a -> a -> Bool
  (<=) :: a -> a -> Bool
  (>) :: a -> a -> Bool
  (>=) :: a -> a -> Bool
  max :: a -> a -> a
  min :: a -> a -> a
  {-# MINIMAL compare | (<=) #-}
-- ...
```

We can see it defines all ordering related operations, and also a minimal set of operations that need to be defined in order to instantiate the type class.

It's also constrained by `Eq`, the type class for equality. Which makes sense, how can we order things if without knowing when they are equal or not.

```
λ> :i Eq
class Eq a where
  (==) :: a -> a -> Bool
  (/=) :: a -> a -> Bool
  {-# MINIMAL (==) | (/=) #-}
-- ...
```

By this definition we can see the constraints. All the `a`s aren't fully polymorphic, they are constrained by the type class (`Eq` or `Ord`).

```
λ> :t (==)
(==) :: Eq a => a -> a -> Bool
```

Which can be any of the types that implement the type class.

Once we apply an argument it becomes more concrete:

```
λ> :t (==) 1
(==) 1 :: (Eq a, Num a) => a -> Bool
Prelude
λ> :t (==) (1 :: Int)
(==) (1 :: Int) :: Int -> Bool
```

## Writing type classes

```haskell
data DayOfWeek
  = Mon
  | Tue
  | Wed
  | Thu
  | Fri
  | Sat
  | Sun

data Date =
  Date DayOfWeek Int

instance Eq DayOfWeek where
  (==) Mon Mon = True
  (==) Tue Tue = True
  (==) Wed Wed = True
  (==) Thu Thu = True
  (==) Fri Fri = True
  (==) Sat Sat = True
  (==) Sun Sun = True
  (==) _ _ = False

instance Eq Date where
  (==) (Date weekday dayOfMonth)
       (Date weekday' dayOfMonth') =
    weekday == weekday' && dayOfMonth == dayOfMonth'
```

Implementing type classes is quite straightforward, we have to define the required functions (the rules) for our type and that's it.

When writing instances of types with polymorphic parameters (like `Date` from the example) we need to make sure those parameters also are constrained.

The following would result in a compile error.

```haskell
data Identity a =
  Identity a

instance Eq (Identity a) where
  (==) (Identity v) (Identity v') = v == v'
```

It does not work because `a` is fully polymorphic (i.e. not constrained), but in order to compare it it needs to implement `Eq`.

```haskell
instance Eq a => Eq (Identity a) where
  (==) (Identity v) (Identity v') = v == v'
```

Making `a` constrained by `Eq` solves the problem 💪

We could also add `Ord` as a constraint, since it also requires `Eq`:

```haskell
instance Ord a => Eq (Identity a) where
  (==) (Identity v) (Identity v') = v == v'
```

Although that would work, it is not good to require more than is needed. Since we are not using any `Ord` functions we are better off with `Eq`.

For some type classes we do not need to write them ourselves, the compiler is smart enough to derive them.

```haskell
data DayOfWeek
  = Mon
  | Tue
  | Wed
  | Thu
  | Fri
  | Sat
  | Sun
  deriving (Eq, Show)
```

## Dispatched by type

> Type classes are defined by the set of operations and values all instances will provide. Type class instances are unique pairings of the type class and a type. They define the ways to implement the type class methods for that type.

> The class definition doesn’t define any terms or code we can compile and execute, only types. The code lives in the instances.

This means the compiler needs to know what types are involved in the operation defined by a type class and then use the implementation defined by those types. Haskell being lazy will delay this as much as possible.

## Conclusions

Type classes are Haskell's approach to polymorphism and one of it's killer features. Not only it avoids [inheritance problems](https://en.wikipedia.org/wiki/Multiple_inheritance#The_diamond_problem)! 🎉 but type classes are a very powerful way of constraining operations to certain types without coupling the types to the operations (like objects do).

The chapter mentioned a few more things about type classes, but this should already give a good practical idea of what type classes are.

P.S.: Don't know why I chose the pizza picture, but now you are hungry too.

[^1]: Philip Wadler, “The Expression Problem” http://homepages.inf.ed.ac.uk/wadler/papers/expression/expression.txt


Originally posted on dev.to/gillchristian.



Here we go with another chapter of the Haskell book from Delft Haskell ...

Type classes

# Types

*Originally posted on [dev.to/gillchristian](https://dev.to/gillchristian/day-13-types-59m6)*.

![Types](https://res.cloudinary.com/practicaldev/image/fetch/s--GRa_NtIZ--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://images.pexels.com/photos/1626481/pexels-photo-1626481.jpeg%3Fauto%3Dcompress%26cs%3Dtinysrgb%26dpr%3D2%26h%3D750%26w%3D1260)

> There are many ways of trying to understand programs. People often rely too much on one way, which is called “debugging” and consists of running a partly-understood program to see if it does what you expected. Another way, which ML advocates, is to install some means of understanding in the very programs themselves.
>
> Robin Milner

I've interrupted the 100DaysOfFP far too long already, partly because I was busy and partly because I was lazy. I'll try to be more constant from now on.

This week on the [Delft Haskell Study Group](https://www.meetup.com/Delft-Haskell-Study-Group/) we went over the 4th and 5th chapter of [Haskell Programming from First Principles](http://haskellbook.com/), "Basic datatypes" and "Types", respectively.

As the last one, this is just my notes and some quotes from the book as a recap of the chapter.

## Basic datatypes

> Haskell has a robust and expressive type system. Types play an important role in the readability, safety, and maintainability of Haskell code as they allow us to classify and delimit data, thus restricting the forms of data our programs can process. Types, also called datatypes, provide the means to build programs more quickly and also allow for greater ease of maintenance.

Sum (or union) types (disjunction):

```haskell
data Bool = False | True
```

Product types (conjunction):

```haskell
data (,) a b = (,) a b

data (,,) a b c = (,) a b c

-- ...
```

Lists:

```haskell
data [] a = [] | a : [a]
```

Numeric types:

- `Int`
- `Integer`
- `Float`
- `Double`
- `Rational`
- `Scientific`

```
λ> :i Num
class Num a where
  (+) :: a -> a -> a
  (-) :: a -> a -> a
  (*) :: a -> a -> a
  negate :: a -> a
  abs :: a -> a
  signum :: a -> a
  fromInteger :: Integer -> a

λ> :i Fractional
class Num a => Fractional a where
  (/) :: a -> a -> a
  recip :: a -> a
  fromRational :: Rational -> a
```

**Data constructors** in Haskell provide a means of creating values that inhabit a given type. Data constructors in Haskell have a type and can either be constant values (nullary) or take one or more arguments, like functions.

**Type constructors** in Haskell are *not* values and can only be used in type signatures. Just as data declarations generate data constructors to create values that inhabit that type, data declarations generate type constructors which can be used to denote that type.

## Types

Haskell is based on [System F](https://en.wikipedia.org/wiki/System_F) and [Hindley-Milner](https://en.wikipedia.org/wiki/Hindley%E2%80%93Milner_type_system) type systems, with some improvements on top.

**What are types for?**

Type systems in logic and mathematics have been designed to impose constraints that enforce correctness.

A type system defines the associations between different parts of a program and checks that all the parts fit together in a logically consistent, provably correct way.

**Type signatures**

```haskell
'f' :: Char
"foo" :: String -- or [Char]
True :: Bool

not :: Bool -> Bool -- function from Bool to Bool
fst :: (a, b) -> a  -- get a tuple's first value

(+) :: Num a => a -> a -> a -- type class constraint
```

The arrow (`->`) is the type constructor.

```
λ> :i (->)
data (->) (a :: TYPE q) (b :: TYPE r)   -- Defined in ‘GHC.Prim’
infixr 0 ->
```
Associates to the right (thus `infixr`).

```haskell
f :: a -> a -> a

-- is the same as

f :: a -> (a -> a)

-- and

map :: (a -> b) -> [a] -> [b]

-- is the same as

map :: (a -> b) -> ([a] -> [b])
```

The function constructor simplified could be `data (->) a b`.

One thing to noticed from that is, functions take only one argument and return one result. Enter *currying*.

> Currying refers to the nesting of multiple functions, each accepting one argument and returning one result, to allow the illusion of multiple-parameter functions.

The benefit of currying is *partial application*.

```
λ> add a b = a + b
λ> addOne = add 1
λ> add 1 2
3
λ> addOne 2
3
λ> 1 + 2
3
λ> add = (+)
λ> add 1 2
3
λ> (+1) 2
3
λ> addOne = (+1)
λ> addOne 2
3
```

### Polymorphism

To me the way Haskell implements polymorphism is one of its key features. I won't go into much detail, just add the book's definitions, since it could be very long otherwise.

*Polymorph*, invented in the early 19th century from the Greek words poly for “many” and morph for “form”. The -ic suffix in polymorphic means “made of.”

In Haskell, polymorphism divides into two categories: *parametric polymorphism* and *constrained polymorphism*.

**Parametricity** is the property that holds in the presence of parametric polymorphism. Parametricity states that the behavior of a function will be uniform across all concrete applications of the function. Parametricity 4 tells us that the function:

```haskell
id :: a -> a
```

Can be understood to have the same exact behavior for every type in Haskell without us needing to see how it was written. It is the same property that tells us:

```haskell
const :: a -> b -> a
```

`const` must return the first value — parametricity and the definition of the type requires it!

```haskell
f :: a -> a -> a
```

Here, `f` can only return the first or second value, nothing else, and it will always return one or the other consistently without changing. If the function `f` made use of (+) or (*), its type would necessarily be constrained by the type class Num and thus be an example of ad-hoc, rather than parametric, polymorphism.

**Ad-hoc polymorphism** (sometimes called “constrained polymorphism”) is polymorphism that applies one or more type class constraints to what would’ve otherwise been a parametrically uniformity of behavior across all concrete applications, the purpose of ad-hoc polymorphism is to allow the functions to have different behavior for each instance. This ad-hoc-ness is constrained by the types in the type class that defines the methods and Haskell’s requirement that type class instances be unique for a given type. For any given combination of type class and a type, such as Ord and Bool, there must only exist one unique instance in scope. This makes it considerably easier to reason about type classes.

```haskell
-- ad-hoc polymorphism via the Num type class
(+) :: Num a => a -> a -> a

-- parametric polymorphism a
c :: a -> a -> a
```

---

This is when the book starts to get interesting. But that's it for now 😄

---

Disclaimer, most of the content of this blogpost is quoted from [Haskell Programming from First Principles](http://haskellbook.com/). I don't meant to plagiarize the book, these are only notes as a recap of chapters 4 and 5.


Originally posted on dev.to/gillchristian.





There are many ways of trying to understand programs. People often rely too much on...

Types

# Lambda calculus

*Originally posted on [dev.to/gillchristian](https://dev.to/gillchristian/day-12-lambda-calculus-29hg)*.

![Lambda calculus](https://res.cloudinary.com/practicaldev/image/fetch/s--X7LTJthZ--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://images.pexels.com/photos/208815/pexels-photo-208815.jpeg%3Fauto%3Dcompress%26cs%3Dtinysrgb%26dpr%3D2%26h%3D750%26w%3D1260)

I figured for some of the days of [#100DaysOfFP](https://twitter.com/gillchristian/status/1080979563700727808) it makes more sense to write something longer than a tweet. So every now and then I'll post in [dev.to](https://dev.to) instead of only a tweet. 😄

This week the [Delft Haskell Study Group](https://www.meetup.com/Delft-Haskell-Study-Group/) started again. I attended last year but didn't put in as much focus as I wanted, so I decided to give it another shot this year.

The goal of the study group is to read some chapter/s of [Haskell Programming from First Principles][hsb] and then go through the exercices together.

My goal for these series is to share a few things from the chapter. More than a blogpost this is a collection of notes that could serve as a recap of the chapter.

## Back to the roots

> Even the greatest mathematicians, the ones that we would put into our mythology of great mathematicians, had to do a great deal of leg work in order to get to the solution in the end.
>
> ― Daniel Tammett

The first chapter of the book doesn't go directly into Haskell and programming but instead introduces us to [Lambda calculus](https://en.wikipedia.org/wiki/Lambda_calculus). Why? Because it's the foundation on top of what Functional Programming, and thus Haskell, is based.

Lambda calculus is "a model of computation devised in the 1930s by Alonzo Church. [...] Functional programming languages are all based on the lambda
calculus" [^1].

**Functional programming**: "a computer programming paradigm that relies on functions modeled on mathematical functions [...] programs are a combination of expressions".

**Expressions**: "include concrete values, variables, and also functions".

**Functions**: are "expressions that are applied to an argument or input, and once applied, can be *reduced* or *evaluated*". And they define a "relation between a set of possible inputs and a set of possible outputs".

## Lambda expressions

In lambda calculus we have: expressions, variables and abstractions. Where expressions are a superset as they can be variables, abstractions or a combination of them.

**Variables**: names for potential inputs of functions.

**Abstractions**: functions. A lambda term consisting of a head (the lamda) and a body, and it's applied to an argument.

**Argument**: a value.

**Application**: applying a lambda function to an argument.

```
λx.x
```

Let's break that down [^2]:

```
λ x . x
^─┬─^
  └────── extent of the head of the lambda.

λ x . x
  ^────── the single parameter of the
          function. This binds any
          variables with the same name
          in the body of the function.

λ x . x
      ^── body, the expression the lambda
          returns when applied. This is a
          bound variable.
```

Functions in lambda calculus are anonymous. But we still call them abstractions as they generalize a problem and it's resolution.


**Alpha equivalence**:

```
λx.x
λd.d
λz.z
```

## Beta reduction

"When we apply a function to an argument, we substitute the input expression for all instances of bound variables within the body of the abstraction. You also eliminate the head of the abstraction, since its only purpose was to bind a variable." [^3]

```
(λx.x) 2
[x ∶= 2]
2
```

The argument can be anything, even other lamda:

```
(λx.x)(λy.y)
[x ∶= (λy.y)]
λy.y
```

Applications in the lambda calculus are *left associative*:

```
(λx.x)(λy.y)z
[x := (λy.y)]
(λy.y)z
[y := z]
z
```

Some variables might be *free*, meaning they aren't bound in the head:

```
λx.xy
```

If we apply such lambda:

```
(λx.xy)z
[x := z]
zy
```

## Multiple arguments

"Each lambda can only bind one parameter and can only accept one argument. Functions that require multiple arguments have multiple, nested heads. When you apply it once and eliminate the first (**leftmost**) head, the next one is applied and so on" [^4]. This is called *currying*.

```
λxy.xy === λx.(λy.xy)
```

**Beta normal form**: when you cannot beta reduce the terms any further.

```
λx.x    -- beta reduced, no arguments to apply

(λx.x)z -- not beta reduced, `z` hasn't been applied
```

**Combinator**: lambda term with no free variables.

```
λxy.x       -- Combinator
λxyz.xz(yz) -- Combinator

λy.x        -- Not combinator
λx.xz       -- Not combinator
```

**Divergence**: lambdas that never reduce to a normal form are said to *diverge*.

```
(λx.xx)(λx.xx)
[x := (λx.xx)]
(λx.xx)(λx.xx)
[x := (λx.xx)]
(λx.xx)(λx.xx)
[x := (λx.xx)]
(λx.xx)(λx.xx)
...
```

In programming, terms that diverge don't produce an actual answer, at least not a meaningful one.

## But why?

After reading this chapter the first time it was not clear to me how all of this applied to Haskell, or Functional Programming in general.

Turns out that the process of reducing the expressions (beta reduction) is how Haskell code evaluates.

The following lambda expression that reduces to `z`

```
(λabc.cba)yz(λwv.w)
[a := y]
(λbc.cby)z(λwv.w)
[b := z]
(λc.czy)(λwv.w)
[c := (λwv.w)]
(λwv.w)zy
[w := z]
(λv.z)y
[v := y]
z
```

It's the equivalent of this in Haskell:

```haskell
-- y = 1
-- z = 2

(\a b c -> c b a) 1 2 (\w v -> w)
(\b c -> c b 1) 2 (\w v -> w)
(\c -> c 2 1) (\w v -> w)
(\w v -> w) 2 1
(\v -> 2) 1
2
```

If we run it in GHCi we get the same result:

```
λ> (\a b c -> c b a) 1 2 (\w v -> w)
2
```

[hsb]: http://haskellbook.com/
[^1]: [Haskell Programming from First Principles][hsb], page 2.
[^2]: [Haskell Programming from First Principles][hsb], page 6.
[^3]: [Haskell Programming from First Principles][hsb], page 7.
[^4]: [Haskell Programming from First Principles][hsb], page 10.


Originally posted on dev.to/gillchristian.



I figured for some of the days of #100DaysOfFP it makes more sens...

Lambda calculus

# tsearch first public version

*Originally posted on [dev.to/gillchristian](https://dev.to/gillchristian/tsearch-first-public-version-50a)*.

![tsearch first public version](https://res.cloudinary.com/practicaldev/image/fetch/s--v_ePipt3--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://images.pexels.com/photos/1110329/pexels-photo-1110329.jpeg%3Fauto%3Dcompress%26cs%3Dtinysrgb%26h%3D750%26w%3D1260)

Last week on the first entry of this devlog I shared how I came up with the idea of writing a search engine for TypeScript functions.

Since then I’ve been working on releasing the first version of the PoC. And I'm glad to say that [tsearch.io](https://tsearch.io) is live since this Monday.

In this entry I want to share how I built this PoC and the limitations it has. 

There are three main parts: 

1. A cli that extracts type information from exported functions of the TS files (`.ts` & `.tsx`) from a directory.
2. A node server that performs searches on the extracted functions.
3. A web client to interact with the server.

## Extracting type information

To extract the types I used [ts-simple-ast](https://github.com/dsherret/ts-simple-ast):

> TypeScript Compiler API wrapper. Provides a simple way to navigate and manipulate TypeScript and JavaScript code.

The idea is simple, load a directory with `ts-simple-ast` and output an array of all the exported functions.

Let’s say we have module, `strs`, with only one exported function:

```ts
// ~/code/strs/src/index.ts

export function replace(search: RegExp, replace: string, str: string) {
  return str.replace(searchValue, replaceValue)
}
```

The output would be something like:

```ts
[
  {
    name: 'replace',
    parameters: [
      {
        name: 'search',
        type: 'RegExp',
      },
      {
        name: 'replace',
        type: 'string',
      },
      {
        name: 'str',
        type: 'string',
      },
    ],
    returnType: 'string',
    module: 'some-module',
  }
]
```

I did not include any extra information of the types, like generics or symbol. For more "elaborate" types (e.g. arrays, functions, unions, generics, etc) this is important because matching cannot be done by comparing strings of type names. For example, `string | number` is the same type as `number | string` but if compared by names, like I'm doing now, they do not match.

The average time for extracting the types of one project is around ~10s. This is fine for one directory, but I wanted to run it on all the packages available in [DefinitelyTyped](https://github.com/DefinitelyTyped/DefinitelyTyped) (DT), 5639 at the moment of writing this 🎉

For that I wrote a [Go program](https://github.com/gillchristian/ts-earch/blob/f2d4b3de75a6997b3fcc3ca755be2f1ecf2673f5/packages/cli/main.go) that runs the extractor on each of those packages and then writes all the output together into a JSON file. I chose Go because of how easy it is to run things in parallel and sync everything.

In my machine (8 core i7 7th gen, 16GB RAM) it takes almost 3 hours running at 100% CPU usage to extract all the types from DT resulting in a 5.8mb JSON file. Not bad at all, but clearly not doable on the 500mb of RAM and 1 core DigitalOcean droplet I have 😂

## Searching

Instead of supporting actual TS type signatures and having to get into parsing it I came up with this very simple query syntax that is trivial to parse. A comma-separated list for the types of the parameters, an arrow (`=>`) and then the return type. The downside is it's not so powerful or even useful for all cases, but hey it's a PoC after all!

```ts
(search: RegExp, replace: string, str: string) => string
// would be
RegExp, string, string => string
```

```ts
<A>(xs: A[]) => A
// would be
A[] => A
```

I still think some kind of syntax as well as a few logical defaults (e.g. single capital letters as generics) could result in a much cleaner and easier way to search than actual valid TS signatures.

```ts
<A, B>(array: A[], fn: ((a: A) => B)) => B[]
// vs
A[], (A => B) => B[]
```

But using valid TS has its merits too. It means one thing less to learn. Also pasting a signature would just work :tm:

As per the search algorithm, [this first iteration](https://github.com/gillchristian/ts-earch/blob/f2d4b3de75a6997b3fcc3ca755be2f1ecf2673f5/packages/search/src/index.ts#L24-L109) is pretty simple, even naive. I came up with a weighing function that assigns a value to the `compared` if the return type matches as well as how many of the types of parameters match against the `query`.

```ts
weight = 0
n = query.parameters.length

if n === compared.parameters.length
  weight += m/n // m: matches by position
  if weight > 0
    weight += m/n + 1 // m/n added twice
else
  weight += m/n // m: matches in any position

if query.returnType === compared.returnType
  weight += 2
```

And then it picks the top hundred ones that scored more than 0. As you can see is not a fancy search algorithm but it already provides some matches for simple searches (e.g. [`A[] => A`](https://tsearch.io/query?q=A%5B%5D%20%3D%3E%20A), [`number => number[]`](https://tsearch.io/query?q=number%20%3D%3E%20number%5B%5D)).

One extra thing I did not mention, if the search query is a single word it searches by function and types names instead. That idea came directly from [Hoogle](https://hoogle.haskell.org/).

## What's next?

Here are some of the challenges I want to tackle next:

- Subscribe to DT repo and run the extractor only on the packages that changed.
- Create a curated list of TS projects that publish their own types and update the extractor to run them.
- Extract more information of the functions types.
- Improve the query syntax and/or support valid TS signatures.
- Make TS semantics part the search algorithm.

There is **A LOT** of room for improvement for sure but I'm happy that people is already interested in the idea and giving it a try. That was exactly the goal of making the project public in such early stage.

For those that would like to contribute I created [`help wanted`](https://github.com/gillchristian/ts-earch/labels/help%20wanted) issues in the repo and will be adding more soon.

I look forward get your feedback, comments and suggestions.

[Until the next time!](https://www.youtube.com/watch?v=-O_cOnGrpY8)


Originally posted on dev.to/gillchristian.



Last week on the first entry of this de...

tsearch first public version

# A crazy idea and a proof of concept

*Originally posted on [dev.to/gillchristian](https://dev.to/gillchristian/a-crazy-idea-and-a-proof-of-concept-2oj7)*.

![A crazy idea and a proof of concept](https://res.cloudinary.com/practicaldev/image/fetch/s--of6w9UAW--/c_imagga_scale,f_auto,fl_progressive,h_420,q_auto,w_1000/https://images.pexels.com/photos/7368/startup-photos.jpg%3Fauto%3Dcompress%26cs%3Dtinysrgb%26dpr%3D2%26h%3D750%26w%3D1260)

In December last year I created the proof of concept (PoC) for an idea I have that seems a bit crazy, at least to me now. It’s a tool to search TypeScript functions and methods by their type signature.

Since I am quite happy with this PoC I decided to commit to the project and work on developing a real useful version.

I plan to share my experience in this devlog because I want to keep track of how the project evolves, what I learn and the things I discover along the way. Also, I guess it will be interesting and useful to others too. To get started I think it makes sense to share how I came up with this idea, what I’ve done already and what is ahead.

![Crazy idea](https://i.imgur.com/dFJAhnT.jpg)
*A crazy idea.*

## The crazy idea

I have been learning about functional programming for a while now. I started with [Professor Frisby's Mostly Adequate Guide to Functional Programming][1] and then went on to try out different languages, Elm, Haskell, Reason, Clojure, Scheme. Which is something I enjoy on itself and encourage you to do too. Learning other languages will give you new approaches and ways to solve problems that you can bring back to the language/s you use.

While playing around with Haskell for last year’s [Advent of Code][2] I used [Hoogle][3] (yeah, Hoogle, with H) a lot.

> Hoogle is a Haskell API search engine, which allows you to search the Haskell libraries on Stackage by either function name, or by approximate type signature.

[Stackage][4] is a package manager for Haskell, with the guarantee that packages will work with each other.

Hoogle turned out to be a really useful tool during development. Which begged the question, why isn’t there such thing for TypeScript? I work with TypeScript on a daily basis and I think it would be a really good addition to the available tools.

The closest thing I found is [Open Symbol by name][5] in VS Code.

## The proof of concept

I shared the idea with my friend [Franco][6], who is much more pragmatic than I am, and he told my “Why don’t you build a PoC and see if it makes sense?”.

As a good PoC it had to be as simple as possible. A way to extract the type signatures from all the exported functions in a local directory and search them through a simple UI.

You can find it [here][7]. For now there is not much you can do with it and documentation is very basic.

[youtube Gf5irOLIFX8]

By the way, I should give credit for the name, `ts-earch`, to Franco.

## Open questions

Developing the PoC convinced me that it is an idea worth working on. But, to be honest, it also left me with more questions than answers.

- Should I use actual TypeScript type signatures for search? Or should I come up with a simpler DSL? In Haskell that is not so much of a problem. Let’s compare the signature of `compose` in both languages.

```haskell
compose :: (b -> c) -> (a -> b) -> a -> c
```

```ts
type Compose = <A, B, C>(f: (b: B) => C, g: (a: A) => B) => (a: A) => C
```

- What about type inference? Say we have a `Person` type, and a function that accepts a person, defined as:

```ts
interface Person {
  name: string
}

const getName = (p: Person) => p.name
```

Searching for `(x: { name: string }) => string` should return `getName` even though the type matches implicitly. How to solve that, I have no idea yet.

- What is the best way to index the types for searching them?
- How to weigh and match types when searching?

These are a few of the open questions I have that I will have to solve. And I am sure there will be more questions along the way.

![The road ahead](https://i.imgur.com/MGsrYzU.jpg)
*The road ahead, definitely not a clear path.*

## One step at a time

To get started it makes sense to have something that people can use and play around with. My short term goal is to adjust a few things and deploy `ts-earch` with all the [DefinitelyTyped][8] packages available for search.

If you have any questions, suggestions or would like to collaborate on the project feel free to [reach out to me on Twitter][9].

Stay tuned for more updates =D

---

[1]: https://github.com/MostlyAdequate/mostly-adequate-guide
[2]: https://adventofcode.com
[3]: https://hoogle.haskell.org/
[4]: https://www.stackage.org/
[5]: https://code.visualstudio.com/docs/editor/editingevolved#_open-symbol-by-name
[6]: https://github.com/fvictorio
[7]: https://github.com/gillchristian/ts-earch/tree/68b515b99076460e25e70c545ab6a6397100f77d
[8]: https://github.com/DefinitelyTyped/DefinitelyTyped
[9]: https://twitter.com/gillchristian





Originally posted on dev.to/gillchristian.



In December last year I c...

A crazy idea and a proof of concept

# Debugging Zsh init times

I recently moved from Ubuntu to MacOS and in the process I made several changes to my dotfiles to make them work. But I wasn't happy with the result, specially because `zsh` initialization time ended up being 3-4s. That doesn't seem like much but for someone that works mostly on the terminal (alacritty, tmux & vim) is a deal breaker.

So I decided to look into the problem and find a way to optimize my zsh init time.

It makes sense to describe a bit what I had in my dotfiles.

- [Antibody](http://getantibody.github.io/) as the plugin manager
- Several [oh-my-zsh](https://github.com/ohmyzsh/ohmyzsh) plugins, most of which I wasn't using
- A custom zsh plugin I built to have _directory based aliases_. I use it mostly to have project related commands (which are usually the same command with a few different tweaks: e.g. different projects require spinning up a server in different ways but they all have the same "run-server" alias)
- zsh syntax highlighting
- zsh suggestions
- [purs](https://github.com/xcambar/purs) as the prompt, which is quite fast

The first attempt was to remove some stuff from my Antibody plugin list. But sadly it didn't improve init speed that much. I didn't know yet how slow my dir_alias plugin was.

After googling for a bit I found out these two articles which basically had all I needed to optimize zsh init time properly.

- [Speeding up my ZSH load](https://carlosbecker.com/posts/speeding-up-zsh/)
- [How to debug zsh startup time](https://blog.askesis.pl/post/2017/04/how-to-debug-zsh-startup-time.html)

### Millennial developer discovers debugging and profiling

I found very useful to be able to debug and profile zsh instead of guessing what could be taking so much time.

**Check zsh init time N times**

```zsh
$ repeat 10 {time zsh -i -c exit}
```

This is useful to find the mean time your zsh takes to initialize. As I said, in my case it was around 3-4s 🐢

**Debug mode**

Prints everything that runs during initialization. This is helpful to see what sort of things are part of your zsh init. I didn't make much use of it but can be handy if you want to make further, more granular improvements.

```zsh
$ zsh -i -v
```

**Profiling**

This was by far the more useful thing I learned about zsh.

Add this line to the top of your `~/.zshrc`:

```zsh
zmodload zsh/zprof
```

And this line to the end, after anything else:

```zsh
zprof
```

Or if you want to play around with the output dump it in a file:

```
zprof > ~/zsh-profiling.txt
```

This will output a table with the top ten slowest commands run during initialization, sorted by the time they took.

```
num  calls                time                       self                name
-----------------------------------------------------------------------------------
 1)    3        10.15    10.15   15.22%     10.15    10.15   15.22%   command_name
 ...
```

### The slow ones

After profiling I found out that my dir_alias plugin was quite slow. It uses a zsh hook to run whenever a directory changes, it checks if the current directory or any parent one contain `.aliasfile`, sets the aliases from them and also cleans up the ones from the previous directory. Which turns out to be slow when done in bash. So, good by friend 👋

But `compaudit` & `compinit` were the slowest ones in my case. They are used to setup completion. Which is something I was not ready to give up. But there's something that can be done. `compinit` reads `~/.zcompdump` every time, which can be changed to only check it once a day.

```zsh
# Take from:  https://gist.github.com/ctechols/ca1035271ad134841284
# Adapted by: https://carlosbecker.com/posts/speeding-up-zsh/

autoload -Uz compinit
if [ $(date +'%j') != $(stat -f '%Sm' -t '%j' ~/.zcompdump) ]; then
  compinit
else
  compinit -C
fi
```

These were the two changes that made the most improvements. Besides that I removed a few other plugins that wasn't using, added a function to lazy load some programs that I rarely need and tidied up a bit my zsh.

Now my init time is around 170-180ms. That's something I can live with 🏎️🎉

## References

Most of the things I share here are taken from these two articles:

- [Speeding up my ZSH load](https://carlosbecker.com/posts/speeding-up-zsh/)
- [How to debug zsh startup time](https://blog.askesis.pl/post/2017/04/how-to-debug-zsh-startup-time.html)


I recently moved from Ubuntu to MacOS and in the process I made several changes to my dotfiles to make them work. But I...

Debugging Zsh init times

# Control flow

From imperative to declarative.

![pipes](https://photos.collectednotes.com/photos/63/7b2a416a-8795-4fa9-abae-e43247230e0b)

## Imperative

Control flow based on statements (`if`, `for`, `while`).

```ts
export const keepEvenInRange = (str: string): number | null => {
  const n = parseInt(str, 10)
  if (Number.isNaN(n)) {
    return null
  }
  if (0 >= n && n <= 100) {
    return null
  }
  if (n % 2 !== 0) {
    return null
  }
  return n
}
```

## Declarative

Control flow based on expressions, data estructures, and composition.

### Option (or Maybe) data type

Encodes the notion of, well, optional values.

Functions that operate with `Option`al values (eg. `map` or `chain`) provide _control flow_ by only transforming the data contained in an `Option` when it's there, but allowing to build these _pipes_ where we work as if the data was there instead of imperatively checking for each operation.

```ts
import * as O from 'fp-ts/lib/Option'
import {pipe} from 'fp-ts/lib/pipeable'

// type Option<Data>      =      None | Some<Data>
// type Either<Err, Data> = Left<Err> | Right<Data>

const parse = (str: string) => {
  const n = parseInt(str, 10)

  return Number.isNaN(n) ? O.none : O.some(n)
}

const isEven = (n: number) =>
  n % 2 === 0 ? O.some(n) : O.none

const isInRange = (from: number, to: number) => (n: number) =>
  from <= n && n <= to ? O.some(n) : O.none

export const keepEvenInRange = (str: string) =>
  pipe(
    str,
    parse,
    O.chain(isEven),
    O.chain(isInRange(0, 100)),
  )
```

### Either data type

Either, is similarly Option, but instead of encoding the notion of optional values, it encodes the the notion of operations that might fail. Either we have a value assosiated with success (by convention) on the `Right` or one assosiated with failure on the `Left`.

Control flow works just like Option. Functions that operate on either (eg. `map` & `chain`) only transform data for the `Right` case, and the same _pipe_ can be built if there were no errors.

```ts
import * as E from 'fp-ts/lib/Either'
import {pipe} from 'fp-ts/lib/pipeable'

// type Option<Data>      =      None | Some<Data>
// type Either<Err, Data> = Left<Err> | Right<Data>

const parseNum = (str: string) => {
  const n = parseInt(str, 10)

  return Number.isNaN(n) ? E.left('not a number') : E.right(n)
}

const isEven = (n: number) =>
  n % 2 === 0 ? E.right(n) : E.left('odd number')

const isInRange = (from: number, to: number) => (n: number) =>
  from <= n && n <= to ? E.right(n) : E.left('not in range')

export const keepEvenInRange = (str: string) =>
  pipe(
    str, 
    parseNum, 
    E.chain(isEven), 
    E.chain(isInRange(0, 100)),
  )
```

### Semantics change, code doesn't

One of the benefits of data estructures oriented control flow is that **by changing the data estructure we can change the semantics of the code without having to change how the code looks**.

And this is possible becasue Option & Either implement the same type classes (Functor, Monad, Applicate, _et al_).

In the example, by switching from Option to Either we now have an error on the `Left`. Which makes it possible to know what went wrong instead of only knowing that something went wrong.

```diff
-import * as O from 'fp-ts/lib/Option'
+import * as E from 'fp-ts/lib/Either'
 import {pipe} from 'fp-ts/lib/pipeable'
 
 // type Option<Data>      =      None | Some<Data>
 // type Either<Err, Data> = Left<Err> | Right<Data>

 const parse = (str: string) => {
   const n = parseInt(str, 10)

-  return Number.isNaN(n) ? O.none : O.some(n)
+  return Number.isNaN(n) ? E.left('not a number') : E.right(n)
 }

 const isEven = (n: number) =>
-  n % 2 === 0 ? O.some(n) : O.none
+  n % 2 === 0 ? E.right(n) : E.left('odd number')

 const isInRange = (from: number, to: number) => (n: number) =>
-  from <= n && n <= to ? O.some(n) : O.none
+  from <= n && n <= to ? E.right(n) : E.left('not in range')

 export const keepEvenInRange = (str: string) =>
   pipe(
     str,
     parse,
-    O.chain(isEven),
-    O.chain(isInRange(0, 100)),
+    E.chain(isEven),
+    E.chain(isInRange(0, 100)),
 )
```