<commit_before>---

<div style='text-align: center;'>
  <img src='assets/haskell-bcn.png' width='400' height='400' style='margin: 0 auto;'>
  <p style='font-size: 72px;'>Haskell Barcelona</p>
  <p style='font-size: 42px;'>12th April 2016 @ <a href='http://itnig.net/es'>Itnig</a></p>
</div>

# Summary

* Introduction / Presentation
    * Who, What, How & When
    * History of Haskell
* Pure functional programming
    * Related concepts
    * Pros & Cons
    * Different approaches
    * Why Haskell?
* A brief introduction to Haskell
* Getting started with Haskell
* Haskell Tools
    * Building/project tools
    * Other

# Who & What

* Organizers
    * <NAME>, Software Engineer @ [TID](http://www.tid.es/es)
    * <NAME>, Software Engineer @ [TID](http://www.tid.es/es)
    * <NAME>, Data Engineer @ [BBVA D&A](http://www.bbvadata.com/)
* Main goals
    * To learn & share:
        * Haskell & "relatives"
        * Pure functional programming
        * Category Theory
    * Meet people around with common interests
    * Open community: share your ideas and expectations

# How & When

* Talks
* Katas
* Discussions (libraries, papers, etc.)
    * Any proposal !?
* ~ Monthly meetings
* Recorded sessions (with slides/code samples available)

# History of Haskell

* Based on Lambda Calculus
* Started ~20 years ago
* Statically typed

# Pure functional programming

From Wikipedia:

> In computer science, <b>functional programming</b> is a programming paradigm
<br> that treats computation as the <b>evaluation</b> of mathematical <b>functions</b>
<br> and avoids <b>changing-state</b> and <b>mutable data</b>. (...) ($\to$ <b>functional</b>)

> It is a <b>declarative</b> (the what) programming paradigm, which means
<br> programming is done with <b>expressions</b> or <b>declarations</b>
<br> instead of <b>statements</b> (the how). (...)

> In functional code, the <b>output value</b> of a function <b>depends only</b>
<br> on the arguments that are <b>input</b> to the function, so calling a
<br> function $f$ twice with the same value for an argument $x$ will produce
<br> the same result $f(x)$ each time. (...) ($\to$ <b>purity</b>)

# Related concepts

* Purity ($\to$ referential transparency):
    * Every function $f$ is a function in the mathematical sense:
        * Every *input* has its corresponding *output*
        * Same *input* produces same *output*, **always**
        * Order does not matter
        * Easy concurrency
* Laziness:
    * Nothing evaluates unless necessary
    * Inner-most expressions first (**call by name**)
    * Allows:
        * Infinite data structures
        * Recursive types
        * Recursive functions
    * Category theory (**functor**, **monoid**, **monad**, and many other buzzwords)
* Reasoning ($\gets$ purity):

>"The central idea of pure functional programming is to structure
<br> our programs in such a way that we can reason about them as
<br> a system of equations just like we can in mathematics." **<NAME>**

# Pros & Cons

* Advantages:
    * Maintainability
    * Testability
    * Increase of productivity
    * Code reuse, easier refactoring
    * Great levels of abstraction (**use carefully!**)
    * Better reasoning
    * Developer happiness

* Disadvantages:
    * For developers, steep learning curve
    * For companies, small pool of developers

# Different approaches

* Functional focuses on **what** and not **how**
* **Expressions** instead of **statements**
* Denotational semantics (code $\to$ mathematical expressions) instead of
<br> operational semantics (code $\to$ abstract machine statements)

# Why Haskell ? (I)

## if...

* Not much used, *academia* language
* *Strange* syntax
* *Strange concepts* (**Monads!?**)
* **Steep** learning curve
* **Immutable**

## because...

* *We are very smart!* (not really, definitely)
* *We want to show off!* (poor us...)
* *We are dumb* (and it helps to program **better**)

# Why Haskell ? (II)

> If Haskell is so great, why isn't it more popular?

<div style='text-align: center'>
  <img src='assets/s1/platon_cave.jpg' width='700' height='500' style='margin: 0 auto;'>
</div>

# Why Haskell ? (III)

Actually it is a really **unfair analogy**:

* Coders solving nowadays increasingly difficult problems using "traditional"
<br> tools are the real heroes of the story
* Using Haskell is more about making your code live more **productive** and **enjoyable**
<br> and not the opposite
* Problems of traditional approaches:
    * Concurrency:
        * OOP encourages *dangerous* and *buggy* design
    * Side effects:
        * **Don't scale**, and **imperative programming** is all about side effects
        * The fact they are **"hidden"** makes them impossible to manage in the large
* How does Haskell tackle this problems?
    * **Explicit side effects**, clear separation between *pure* and *impure* code
    * **Immutability**
    * **Functional patterns** $\to$ composability
    * A very expressive **type system**

# A brief introduction to Haskell

* Expressions<br>
* Types<br>
* Functions<br>
* Infix operators<br>
* Bindings<br>
* Basic data types<br>
* Typeclasses<br>
* Functional patterns<br>

# Expressions

* Everything in Haskell is an *expression* or *declaration*
* Basic unit of a Haskell program
* Expressions may be:
    * Values
    * Combination of values
    * Functions applied to values
* An Expression can be composed of sub-expressions
* Expressions *evaluate* to a *result*<commit_msg>Getting rid of Plato, some changes to OOP problems<commit_after>---

<div style='text-align: center;'>
  <img src='assets/haskell-bcn.png' width='400' height='400' style='margin: 0 auto;'>
  <p style='font-size: 72px;'>Haskell Barcelona</p>
  <p style='font-size: 42px;'>12th April 2016 @ <a href='http://itnig.net/es'>Itnig</a></p>
</div>

# Summary

* Introduction / Presentation
    * Who, What, How & When
    * History of Haskell
* Pure functional programming
    * Related concepts
    * Pros & Cons
    * Different approaches
    * Why Haskell?
* A brief introduction to Haskell
* Getting started with Haskell
* Haskell Tools
    * Building/project tools
    * Other

# Who & What

* Organizers
    * <NAME>, Software Engineer @ [TID](http://www.tid.es/es)
    * <NAME>, Software Engineer @ [TID](http://www.tid.es/es)
    * <NAME>, Data Engineer @ [BBVA D&A](http://www.bbvadata.com/)
* Main goals
    * To learn & share:
        * Haskell & "relatives"
        * Pure functional programming
        * Category Theory
    * Meet people around with common interests
    * Open community: share your ideas and expectations

# How & When

* Talks
* Katas
* Discussions (libraries, papers, etc.)
    * Any proposal !?
* ~ Monthly meetings
* Recorded sessions (with slides/code samples available)

# History of Haskell

* Based on Lambda Calculus
* Started ~20 years ago
* Statically typed

# Pure functional programming

From Wikipedia:

> In computer science, <b>functional programming</b> is a programming paradigm
<br> that treats computation as the <b>evaluation</b> of mathematical <b>functions</b>
<br> and avoids <b>changing-state</b> and <b>mutable data</b>. (...) ($\to$ <b>functional</b>)

> It is a <b>declarative</b> (the what) programming paradigm, which means
<br> programming is done with <b>expressions</b> or <b>declarations</b>
<br> instead of <b>statements</b> (the how). (...)

> In functional code, the <b>output value</b> of a function <b>depends only</b>
<br> on the arguments that are <b>input</b> to the function, so calling a
<br> function $f$ twice with the same value for an argument $x$ will produce
<br> the same result $f(x)$ each time. (...) ($\to$ <b>purity</b>)

# Related concepts

* Purity ($\to$ referential transparency):
    * Every function $f$ is a function in the mathematical sense:
        * Every *input* has its corresponding *output*
        * Same *input* produces same *output*, **always**
        * Order does not matter
        * Easy concurrency
* Laziness:
    * Nothing evaluates unless necessary
    * Inner-most expressions first (**call by name**)
    * Allows:
        * Infinite data structures
        * Recursive types
        * Recursive functions
    * Category theory (**functor**, **monoid**, **monad**, and many other buzzwords)
* Reasoning ($\gets$ purity):

>"The central idea of pure functional programming is to structure
<br> our programs in such a way that we can reason about them as
<br> a system of equations just like we can in mathematics." **<NAME>**

# Pros & Cons

* Advantages:
    * Maintainability
    * Testability
    * Increase of productivity
    * Code reuse, easier refactoring
    * Great levels of abstraction (**use carefully!**)
    * Better reasoning
    * Developer happiness

* Disadvantages:
    * For developers, steep learning curve
    * For companies, small pool of developers

# Different approaches

* Functional focuses on **what** and not **how**
* **Expressions** instead of **statements**
* Denotational semantics (code $\to$ mathematical expressions) instead of
<br> operational semantics (code $\to$ abstract machine statements)

# Why Haskell ? (I)

## If...

* Not used that much, *academia* language
* *Strange* syntax
* *Strange concepts* (**Monads!?**)
* **Steep** learning curve

## because...

* *We are very smart!* (not really, definitely)
* *We want to show off!* (poor us...)
* *We are dumb* (and it helps to program **better**)

# Why Haskell ? (II)

* Problems of current approaches:
    * OOP solutions to concurrency and managing side effects:
        * concurrency $\to$ hiding locks in objects to protect data
        * side effects $\to$ noting side effects in naming/documentation (SetPassword is obviously side effecting)
    * The problem is in the scale and composition:
        * locks *don't compose*, and hiding them makes things worse
        * obvious side effecting methods are not so obvious when composed in layers of side effecting methods
    * Summing up, OOP basic tenets encourage *dangerous* and *buggy* design
        * Data hiding, sharing and mutation combined $\to$ recipe for *races* and *unexpected side effects*
* How does Haskell tackle these problems?
    * **Explicit side effects**, clear separation between *pure* and *impure* code
    * **Immutability**
    * **Functional patterns** $\to$ composability
    * A very expressive **type system**

# A brief introduction to Haskell

* Expressions<br>
* Types<br>
* Functions<br>
* Infix operators<br>
* Bindings<br>
* Basic data types<br>
* Typeclasses<br>
* Functional patterns<br>

# Expressions

* Everything in Haskell is an *expression* or *declaration*
* Basic unit of a Haskell program
* Expressions may be:
    * Values
    * Combination of values
    * Functions applied to values
* An Expression can be composed of sub-expressions
* Expressions *evaluate* to a *result*
{'fraction_non_alphanumeric': 0.12156682027649769, 'fraction_numerical': 0.00423963133640553, 'mean_word_length': 3.6974025974025975, 'pattern_counts': {'":': 0, '<': 126, '<?xml version=': 0, '>': 135, 'https://': 0, 'lorem ipsum': 0, 'www.': 6, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '1380587', 'n_tokens_mistral': 3313, 'n_tokens_neox': 3109, 'n_words': 1248}