Goal of this article is to describe the concept of Abstraction in an understandable manner. It should cover the process of learning and display how abstraction works in empirical mode and in self-contained (mathematical) mode, as well as providing information about the pattern recognition and noticing similarities that trigger abstraction.

What is abstraction in the big picture? It is a process of creating a framework to think about a class of problems or processes. In this framework are normally included three things — objects, relations and operations.

Below we provide a motivational example for empirical abstraction.

Humans noticed that different similar objects can be grouped and counted. Sheep or horses, amount of soldiers in an army, all different, but similar and we can calculate the precise quantity of those. This gives raise to natural numbers, such as $ 1 $, $ 2 $, $ 3 $ , $ \cdots{} $. Interestingly, when armies fight and the amount of soldiers decrease due to injury or, G-d forbid, death, the quantity changes, which gives raise to the operation of subtraction. When new cattle is born, the amount of sheep in the herd increases, which gives raise to addition.

Here is the summary of how empirical abstraction works:

- Objects that represent generalized version of entities that we work with while dealing with a class of problems or the process we abstract over. In the example with natural numbers, entities are things that are similar to each other — sheep, soldiers, et cetera. We abstract over the type of entity and the order in which we count those, assigning numbers to groups based on result of counting entities in those. Object in this example is a number.
- Relations that represent how objects compare to each other. In our example, relation would be “belonging to a group of similar things”, which is an abstraction over “soldiers belonging to west army, soldiers belonging to north army, sheep in Joe’s herd”.
- Operations on objects which allow us to get a desired result, which is either a solution for a problem or a useful description of a process. Operations in the example we’re working with abstract over events, such as birth of cattle or injury of soldiers.

Notice, that the example is abstraction that is purely based on experience. For example, it doesn’t give raise to negative numbers (such as -5, -42), or to real numbers, such as (9¾, 13.37).

HW #1: Which experience, that we should experience daily, can give raise to the abstract notion of real numbers?

This is a perfect example of empirical abstraction, the one that was made through experience.

Mathematics for at least a couple of last centuries, however, strives to bring the abstraction approach to the absolute, becoming self-contained, disregarding relation to the physical and social world. For instance, when we’re talking about natural numbers as mathematicians, we prefer to disregard things we can do with numbers, such as counting sheep or calculating losses in our army, but instead provide a system of objects and operations in the vacuum of itself. We will discuss how can it be so useful later on.

Now let’s ponder on the concept of this different sort of abstraction a little bit more (the explanation we provide here is almost completely taken from a paper by Michael Mitchelmore et al, that surveys the proceedings in understanding and defining abstraction in mathematics and mathematical learning[2]).

- Mathematics uses everyday words, but their meaning is defined precisely in relation to other mathematical terms and not by their everyday meaning. Even the syntax of mathematical argument (such as proofs) is different from the syntax of everyday language and is again quite precisely defined. These ideas are demonstrated pretty well in the first chapter of “Proofs and Fundamentals” by E. D. Bloch[1].
- Mathematics contains objects which are unique to itself. For example, although everyday language occasionally uses symbols like x and p, objects like x^p or sqrt(-1) are unknown outside mathematics.
- A large part of mathematics consists of rules for operating on mathematical objects and relationships. It is important that students learn to manipulate symbols using these rules and no others. For example, if we have a category that contains as objects things that aren’t necessarily numeric, and a custom operation “+” is defined on it, we can’t use operation “×” just because we feel like addition and multiplication are closely related. We can think of operations on mathematical objects as of rules of a board game, such as the way pieces move in chess.

These three aspects of mathematics make it unfeasible, or — even stronger — impossible to construct objects, relations and operations using empirical abstraction. Instead, an axiomatic approach is used, which we will illustrate, continuing the example of natural numbers.

Here is an accurate enough description of the most famous way in which natural numbers are defined in mathematics. It is called “Peano Axioms”.

- $ 0 $ is a number.
- If $ a $ is a number, $ S(a) $ is a number.
- There is no such number $ a $ that $ 0 = S(a) $.
- $ m = n $ if and only if $ S(m) = S(n) $
*“If and only if” is often written as “iff” in mathematical texts*. - If a set $ I $ contains $ 0 $ and also successor of every number in $ I $ then $ I $ contains all numbers.

From those axioms, we can formally derive true statements. Those are called “lemmas” or “theorems” and the derivation is called “a proof”.

For instance, based on this list of axioms, we can prove that if $ m $ and $ n $ are equal then successor of successor of $ n $ is equal to successor of successor of $ m $.

HW#2 (optional): Prove it.

If we will run around, making an axiomatic out of every interesting abstraction, we’ll quickly get tangled with a bunch of different incompatible chunks of mathematics. However, we would like to have a way to develop axioms and prove statements with those (or, in other words, develop theories) completely independently. This is why in mathematics there is a notion of foundations. A foundation is a special bunch of axioms that provide mathematician with everything necessary to unify their new shiny theory with the work of other mathematicians on their shiny theories. The result of a process of specifying how exactly does a theory map onto a foundation is called “a model”. For example, a model of the Peano axioms is a 3-tuple $ (N, 0, S) $, where $ N $ is an infinite set, $ 0 \in N $, and $ S: N \to N $ satisfies Peano Axioms. This maps well to foundations such as ZF set theory.

Even though mathematics is developed as a thing in itself, it is useful.

Mathematics allows us to carry out computations. Starting from calculating change in a shop, ending in solving equations for some variable given parameters. For example, using calculations we can decide how many stops can we afford to make in order to travel from one country in Europe to another under a certain amount of time.

Mathematics is a powerful, if not the only proper tool for building models. Models are never 100%-precise, but useful to predict outcomes of processes in reality. For instance, we can have a model of a bet winning given historical data which is inherently probabilistic, or we can have a model of a rocket vertically landing on a launchpad, so that we don’t have to construct expensive rockets to check their properties.

Another important application of mathematics is reasoning. Example of mathematically-powered reasoning can be found in computer programming, where it allows us to extract interesting information about our programs. The kinds of this information are vast: starting from complexity analysis, ranging over simple type systems and type systems with dependent types (where you can write type-level programs), to complex and featureful proof assistants to generate proofs about the properties of software. Mathematical logic also might help in mundane reasoning.

Theories such as category theory show correspondence between different fields of knowledge, pointing how they map to each other, making results from one field applicable to another field.

Finally, let’s formulate informally the answer to the question “how to learn mathematics?”.

In order to learn mathematics, we have to see patterns and similarities in a problem domain. Often it is hard to see those, so we can use guided approach, where those similarities are suggested by an educator. As we are sure that those similarities aren’t noise, but are indeed characteristic to a given problem domain, we empirically abstract over those. Here we as students should try our best to come up with abstractions ourselves, keeping in mind the problems we want to solve. If we are studying with an educator, an educator should criticize our abstractions and point out some things that we might have missed. At the end of this back-and-forth, we should end up with a class of good-enough abstractions for the problem domain that help us solve practical problems. Next step is to play with those empirical abstractions and build up an intuition about how they work. With the intuition in place, we can now learn corresponding mathematical abstractions. This process will be reinforced with developed intuition, hence it should be relatively simple to fit mathematical abstractions in our head (simple does not necessarily mean easy!). In order to verify success in learning of mathematical abstractions, we should periodically solve exercises and mathematical problems. Now that we have mastered a mathematical theory or its part, vast opportunities lie as we proceed. We can decide to use it in practice, we can see how this theory correlates with other theories, check if there are generalizations of it. Most importantly though, have fun while learning and using your knowledge!

References:

[1] E.D.Bloch: Proofs and Fundamentals — http://www.unalmed.edu.co/~cemejia/doc/bloch.pdf

[2] Michael Mitchelmore et al: Abstraction In Mathematics and Mathematics Learning — http://www.emis.de/proceedings/PME28/RR/RR031_Mitchelmore.pdf

]]>Here we continue to re-implement Lens Over Tea.

Ongoing work in covering the entire document can be found in my slides repo.

```
{-# LANGUAGE RankNTypes #-}
module Main where
import Data.Functor (($>))
import Data.Functor.Compose (Compose (..))
------------------------------------------------------------------------
type Lens s t a b = forall f . (Functor f) => (a -> f b) -> s -> f t
type Lens' s a = Lens s s a a
ix :: Int -> Lens' [a] a
ix i f [] = lrgErr
ix 0 f (x:rest) = (:rest) <$> f x
ix i f (x:rest)
| i < 0 = geqErr
| True = (x:) <$> ix (i-1) f rest
------------------------------------------------------------------------
type Getting s a = (a -> Const a a) -> s -> Const a s
view :: Getting s a -> s -> a
view l = getConst . l Const
------------------------------------------------------------------------
type Setting s t a b = (a -> Identity b) -> s -> Identity t
over :: Setting s t a b -> (a -> b) -> s -> t
over l f = runIdentity . l (Identity . f)
------------------------------------------------------------------------
-- _1 :: Functor f => (a -> f b) -> (a, x) -> f (b, x)
_1 :: Lens (a, x) (b, x) a b
_1 g (k, l) = g k >$< (,l)
-- _2 :: Functor f => (a -> f b) -> (x, a) -> f (x, b)
_2 :: Lens (x, a) (x, b) a b
_2 g (k, l) = g l >$< (k,)
-- Make a lens out of a getter and a setter.
lens :: (s -> a) -> (s -> b -> t) -> Lens s t a b
lens get set g y = (g . get) y >$< set y
-- Combine 2 lenses to make a lens which works on Either. (It's a good idea
-- to try to use bimap for this, but it won't work, and you have to use
-- explicit case-matching. Still a good idea, tho.)
--
-- :: Functor f1, f2, f3 => ((a -> f1 b) -> s1 -> f1 t1 ) ->
-- ((a -> f2 b) -> s2 -> f2 t2 ) ->
-- (a -> f3 b) -> Either s1 s2 -> f3 (Either t1 t2)
choosing :: Lens s1 t1 a b -> Lens s2 t2 a b
-> Lens (Either s1 s2) (Either t1 t2) a b
choosing l1 _ g (Left y) = l1 g y >$< Left
choosing _ l2 g (Right y) = l2 g y >$< Right
-- Modify the target of a lens and return the result. (Bonus points if you
-- do it without lambdas and defining new functions. There's also a hint
-- before the end of the section, so don't scroll if you don't want it.)
(<%~) :: Lens s t a b -> (a -> b) -> s -> (b, t)
(<%~) l h = l (\x -> (h x, h x))
-- Modify the target of a lens, but return the old value.
(<<%~) :: Lens s t a b -> (a -> b) -> s -> (a, t)
(<<%~) l h = l (\x -> (x, h x))
-- There's a () in every value. (No idea what this one is for, maybe it'll
-- become clear later.)
united :: Lens' s ()
united g = ($>) $ g ()
```

]]>THC (Tiny Haskell Cheatsheet) showing the concept of a smart constructor.

```
{-# LANGUAGE OverloadedStrings #-}
module Main ( YandexWallet -- NB! We're hiding constructors in exports!
, yandexWallet -- The only constructor for YandexWallet type!
, main
) where
import Control.Exception (assert)
import qualified Data.Text as T
data YandexWallet = YandexWallet T.Text deriving (Show)
yandexWallet :: T.Text -> YandexWallet
yandexWallet x = assert (T.length x == 14) $ YandexWallet x
main = do
putStrLn $ show $ yandexWallet "6666 6666 6666"
putStrLn $ show $ yandexWallet "phayul"
```

will produce:

```
Mon Nov 23 23:45:08:450160612 sweater@chill ~
λ ghci -XOverloadedStrings /tmp/Main.hs
GHCi, version 7.10.2: http://www.haskell.org/ghc/ :? for help
[1 of 1] Compiling Main ( /tmp/Main.hs, interpreted )
Ok, modules loaded: Main.
*Main> main
YandexWallet "6666 6666 6666"
*** Exception: /tmp/Main.hs:13:18-23: Assertion failed
```

Notice, that `assert`

from Control.Exception is not the only way to make sure that smart constructors construct correct values, you can do all sorts of clever things in those. The important part of the concept is that you hide default constructors and only export the type, then you write custom constructors for it and export all of those.

While proof-reading lens over tea series, I’ve decided to challenge myself with the following — without reading code presented in the article series, implement important functions mentioned in the article.

I think that series like that are perfect for teaching huge libraries such as length.

```
{-# LANGUAGE RankNTypes #-}
module Main where
import Data.Functor (($>))
import Data.Functor.Compose (Compose (..))
geqErr = error "index must be geq 0"
lrgErr = error "index too large"
iGuard x y z f =
if x < 0
then geqErr
else f x y z
type Lens s a = (a -> a) -> s -> (a, s)
type LensL s a = (a -> [a]) -> s -> (a, [s])
type LensF s a = forall f . (Functor f) => (a -> f a) -> s -> (a, f s)
ix :: Int -> Lens [a] a
ix i f xs =
iGuard i f xs ixDo
where
ixDo _ _ [] = lrgErr
ixDo 0 f (x:rest) = (x, ((f x):rest))
ixDo i f (x:rest) = let (x', rest') = ixDo (i-1) f rest in
(x', x:rest')
ixl :: Int -> LensL [a] a
ixl i f xs =
iGuard i f xs ixDo
where
ixDo _ _ [] = lrgErr
ixDo 0 f (x:rest) = (x, [(x':rest) | x' <- f x])
ixDo i f (x:rest) = let (x', rest') = ixDo (i-1) f rest in
(x', map (x:) rest')
ixf :: Int -> LensF [a] a
ixf i f xs =
iGuard i f xs ixDo
where
ixDo _ _ [] = lrgErr
ixDo 0 f (x:rest) = (x, (:rest) <$> f x)
ixDo i f (x:rest) = let (x', rest') = ixDo (i-1) f rest in
(x', (x:) <$> rest')
---
type LensF1 s a = forall f . (Functor f) => (a -> f a) -> s -> f s
-- |
-- λ> let (Pair x y) = ixf1 6 (\x -> Pair (Const x) [666]) [1..10]
-- λ> (getConst x,y)
-- (7,[[1,2,3,4,5,6,666,8,9,10]])
ixf1 :: Int -> LensF1 [a] a
ixf1 i f xs =
iGuard i f xs ixDo
where
ixDo _ _ [] = lrgErr
ixDo 0 f (x:rest) = (:rest) <$> f x
ixDo i f (x:rest) = (x:) <$> ixDo (i-1) f rest
```

]]>Boys, girls, humans.

Recently I’ve devoured a Soviet book in Category theory and want something more.

That being said, I’m glad to announce that I’m starting a HoTT study group in Zagreb. Going from functional programming to type theory to topology and all the way back sounds like an awesome trip.

I’ll coordinate with functional programming user group (did you know we have one in Zg?) Here is a talk that may motivate such a study group.

We will, of course, eventually dig through “Homotopy Type Theory: Univalent Foundations of Mathematics”.

Before that we want to organize the first meeting to get acquainted with each other and see how do we want to approach this SG.

May the types be with us. To get included into the mail thread, contact me.

]]>Interesting read (both code-wise and discussion-wise). Even declined PRs are worth reading.

Pop-sci journal that actually feels like it’s written by paparazzi in a very distinctive scandalous language. Enjoyed this particular article, maybe there’s more, but I feel like it gets tiresome very fast.

Another article touching the fact that human conventions and perception are arbitrary.

This article is great because if you read between the lines, you actually get to understand the mechanism UEFI uses to boot.

I’m not saying that UEFI is a good idea, I’m saying that this article plus some thinking provides one with a generic way to make UEFI-bootable iso`s.

]]>- Shift+a — create a primitive (we should have something to edit first, don’t we?)
- Tab — enter edit mode
- z — object shading switch (toggles see-through “wireframe”)
- Ctrl+r — enter median-cut mode (you can use mouse wheel to increase number of cuts)
- N — transform panel
- Ctrl+l — link certain things across selection

- b
- box with left-click — add vertices to selection
- box with middle-click — remove vertices from selection

- Shift+left-click — add a vertex to selection
- Shift+right-click — remove a vertex from selection
- a — toggle select all vertices

- Ctrl+r — normal (orthogonal) cut
- scroll-up — increase number of cuts
- scroll-down — decrease number of cuts
- right-click — apply (after application, you can use
`g`

/`s`

to move or scale selected vertices)

- Ctrl+b — corner cut (Bevel)
- move mouse — place the cut
- scroll-up — increase number of cuts
- scroll-down — decrease number of cuts

- NUM5 — toggle isometry
- NUM7 — top ortho
- NUM1 — front ortho
- NUM3 — right ortho

- Shift+s — cursor menu
- Ctrl+Alt+Shift+c — origin and center of mass manipulation

```
time blender \
-b ./file.blend \
-o "/tmp/out$(date --iso-8601=seconds)" \
-F JPEG \
-P ~/memoricide/goodies/misc/gpurenderpre.py \
-x 1 -f 1
```

where `gpurenderpre.py`

is

```
import bpy
bpy.context.scene.render.engine = 'CYCLES'
bpy.data.scenes['Scene'].cycles.samples=500
bpy.context.scene.cycles.device = 'GPU'
```

]]>```
>>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>=
>>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>
>>= >>= >>= $ ∷∷∷∷ >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>=
>>= >>= >>= ∷∷∷∷∷∷∷∷ >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>=
>>= >>= >>= ∷∷∷∷∷∷∷∷∷∷∷∷ >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= $
>>= >>= >>= ∷∷∷∷∷∷∷∷∷ >>= >>= >>= >>= >>= >>= >>= >>= >>= >>=
>>= >>= >>= ◇◇ ∷∷∷∷ >>= >>= >>= >>= >>= >>= >>= >>= >>= >>=
>>= >>= >>= ◇◇◇ >>= >>= >>= >>= >>= >>= >>= >>= >>= >>=
>>= >>= >>= $ ◇◇◇ >>= >>= >>= >>= >>= >>= >>= >>= >>= >>
>>= >>= >>= >> ◇◇◇ >>= >>= >>= >>= >>= >>= >>= >>= >>= $
>>= >>= >>= >>= ◇◇◇ >>= >>= >>= >>= >>= >>= >>= >>= >>=
>>= >>= >>= >>= ◇◇◇ >>= >>= >>= >>= >>= >>= >>= >>= >>=
>>= >>= >>= >>= ◇◇◇ >>= >>= >>= >>= >>= >>= >>= >>= >>=
>>= >>= >>= >>= $ ◇◇◇ >>= >>= >>= >>= >>= >>= >>= >>= >>
>>= >>= >>= >>= >> ◇◇◇ ∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷ >>= >>= >>= >>
>>= >>= >>= >>= >>= ◇◇◇ ◇◇ >>= >>= >>= $
>>= >>= >>= >>= >>= ◇◇◇ ◇◇◇ >>= >>= >>=
>>= >>= >>= >>= >>= ◇◇◇ ◇◇◇ >>= >>= >>=
>>= >>= >>= >>= >>= $ ◇◇◇ ◇◇◇ ∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷ >>= >>= >>=
>>= >>= >>= >>= >>= >> ◇◇◇ ∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷ >>= >>= >>=
>>= >>= >>= >>= >>= >>= ◇◇◇ ∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷ >>= >>= >>=
>>= >>= >>= >>= >>= >>= ◇◇◇ >>= >>= >>= >>= >>= >>= >>=
>>= >>= >>= >>= >>= >>= ◇◇◇ >>= >>= >>= >>= >>= >>= >>=
>>= >>= >>= >>= >>= >>= ◇◇◇ ∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷ >>= >>= >>=
>>= >>= >>= >>= >>= >>= ◇◇◇ ◇◇ >>= >>= >>
>>= >>= >>= >>= >>= >> ◇◇◇ ◇◇◇ >>= >>= $
>>= >>= >>= >>= >>= $ ◇◇◇ ◇◇◇ >>= >>=
>>= >>= >>= >>= >>= ◇◇◇ ◇◇◇ >>= >>=
>>= >>= >>= >>= >>= ◇◇◇ ◇ ∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷ >>= >>=
>>= >>= >>= >>= >>= ◇◇◇ >◇◇ ∷∷∷∷∷∷∷∷∷∷∷∷∷∷∷ >>= >>= $
>>= >>= >>= >>= >> ◇◇◇ $ ◇◇◇ ∷∷∷∷∷∷∷∷∷∷∷∷ >>= >>= >>=
>>= >>= >>= >>= $ ◇◇◇ >>= ◇◇◇ >>= >>= >>= >>= >>=
>>= >>= >>= >>= ◇◇◇ >>= $ ◇◇◇ >>= >>= >>= >>= >>=
>>= >>= >>= >>= ◇◇◇ >>= >>= ◇◇◇ >>= >>= >>= >>= >>
>>= >>= >>= >>= ◇◇◇ >>= >>= ◇◇◇ >>= >>= >>= >>= $
>>= >>= >>= >> ◇◇◇ >>= >>= >> ◇◇◇ >>= >>= >>= >>=
>>= >>= >>= $ ◇◇◇ >>= >>= >>= ◇◇◇ >>= >>= >>= >>=
>>= >>= >>= ◇◇◇ >>= >>= >>= $ ◇◇◇ >>= >>= >>= >>=
>>= >>= >>= ◇◇◇ >>= >>= >>= >>= ◇◇◇ >>= >>= >>= >>
>>= >>= >>= ◇◇◇ >>= >>= >>= >>= ◇◇◇ >>= >>= >>= $
>>= >>= >> ◇◇◇ >>= >>= >>= >>= >> ◇◇◇ >>= >>= >>=
>>= >>= $ ◇◇◇ >>= >>= >>= >>= >>= ◇◇◇ >>= >>= >>=
>>= >>= ◇◇◇ >>= >>= >>= >>= >>= $ ◇◇◇ >>= >>= >>=
>>= >>= ◇◇◇ >>= >>= >>= >>= >>= >>= ◇◇◇ >>= >>= >>=
>>= >>= ◇◇◇ >>= >>= >>= >>= >>= >>= $ ◇◇ >>= >>= >>= $
>>= >> ◇◇◇ >>= >>= >>= >>= >>= >>= >>= ◇ >>= >>= >>= >>=
>>= $ ◇◇◇ >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>=
>>= ◇◇◇ >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>=
>>= ◇◇◇ >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>=
>>= ◇◇◇ >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= $
$ ◇◇◇ >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>
>> ◇◇ >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>=
>>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>
>>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>= >>=
```

]]>Even though I do think that this post is pretty pointless, I found it entertaining. Besides, I do agree with tedu when he says

The point here isn’t to pick on rust. I could have written the same program with the same flaw in go, or even haskell if I were smart enough to understand burritos. The point is that if we don’t actually understand what vulnerabilities like Heartbleed are, we are unlikely to eliminate them simply by switching to a magic vulnerability proof language. Everyone may have heard about Heartbleed, but that doesn’t necessarily make it a good exemplar.

Perhaps Heartbleed is a just a stand in term referring not to Heartbleed itself, but rather any number of other bugaboos. I’m not sure that’s better. Vulnerabilities like Heartbleed but not too much like Heartbleed is a poorly defined class. It’s hard to assess any claims about such a class.

When speaking about vulnerabilities and how they can be resolved, we should try to be precise and accurate. The hype around Heartbleed (and ShellShock, etc.) makes them attractive targets to latch an argument on to, but in doing so we must be careful that our chosen example fits the argument. Misidentified problems lead to misapplied solutions.

Silver-bullet cultists, static-typing fundamentalists and functional programming purists shouldn’t be taken seriously because fundamentalism in any shape and form blinds its adept and makes her detached from reality.

That being said, I find the post pointless because, after stripping fundamentalist bullshit, we’re left with a statement like “while writing idiomatic parsers in functional style we severely reduce the probability of having leaky buffers”. Ugly optimizations, however, oftentimes break the idiomaticness of the code, hence the whole discussion retards to a simple pair of non-contradicting statements not worth the holy war.

Docker is the most famous LXC/AUFS wrapper. I didn’t care enough to dig it even though we were using it in production with one of the companies I was working for.

In the linked posts is pretty reasonable critique of this library. Looks like my gut feeling about projects in Go is yet to fail me.

A later, more complete version of this paper is available as well.

This paper describes Hydra, the current CI system used to test Nix expressions. A perfect thing to read before you make your first Hydra deployment.

Interesting project, use case of which is limited to one thing — simple shell-scripting for teams of Haskell programmers/dev-ops. I really hope that someone will either write a translator from Turtle to Shell, or nobody will going to ever use this library for writing user-facing scripts.

Mirror:

```
curl \
http://media.ccc.de/.../...hd.rss | \
grep -oE "<link>.*</link>" | grep -oE "http[^<]*"
```

Here we parse out links from HD rss of Chaos Communication Congress and get the torrent link to downolad it with transmission or rtorrent. If you are an asshole and don’t want to use a torrent, you can just use this mirror to get the videos. Consider putting up a mirror if you do so, to give back the traffic.

```
# Download CCC talks in English
m="http://mirror.netcologne.de/CCC/congress/2014/h264-hd/"
for x in \
$(curl $m \
| grep -oE 'href="[^"]*"' \
| grep -oE '31c3.*-en[^"]*'); do wget "$m$x"
done
```

https://github.com/manpages/dotfiles/blob/master/nixos/hydra.nix#L8-L26

]]>```
ffmpeg -i ~/in -vf scale=320:-1 -t 10 -r 12 -ss 186 \
-loop 0 out.gif
```

It might be not obvious that here -loop 0 means that GIF will has no delay between loops. As one might guess, -r defines rate, -t defines the length of period to dump and -ss denotes the offset.

Result:

`mv ~/.ghc/x86_64-linux-7.8.4{,.old}`

Equivalent of changing mirrorlist options in Arch Linux —

```
nix-channel --add \
https://nixos.org/channels/nixpkgs-unstable
```

Equivalent of `pacman -Sy`

(synchronize package database) —

`nix-channel --update`

Equivalent of `pacman -Su`

(install fresh stuff) —

`nixos-rebuild switch --upgrade`

]]>When in doubt,

`mv ~/.ghc/x86_64-linux-7.8.4{,.old}`

especially if you do a lot of library testing outside nix shell.

Nix can’t collect garbage from your local ghc-pkg cache.

]]>JavaScript stands out, even in the Haskell world:

```
...
[ 2 of 149] Compiling Yi.Syntax.Layout
[ 3 of 149] Compiling Yi.Keymap.Vim.MatchResult
[ 4 of 149] Compiling Yi.Keymap.Vim.Digraph
[ 5 of 149] Compiling Yi.Keymap.Completion
[ 6 of 149] Compiling Parser.Incremental
[ 7 of 149] Compiling Yi.IncrementalParse
[ 8 of 149] Compiling Yi.Event
[ 9 of 149] Compiling Yi.UI.Vty.Conversions
[ 10 of 149] Compiling Yi.JumpList
[ 11 of 149] Compiling Yi.KillRing
[ 12 of 149] Compiling Yi.Debug
[ 13 of 149] Compiling Data.DelayList
[ 14 of 149] Compiling Control.Exc
[ 15 of 149] Compiling System.CanonicalizePath
[ 16 of 149] Compiling System.FriendlyPath
[ 17 of 149] Compiling Yi.Layout
[ 18 of 149] Compiling Yi.UI.Pango.Layouts
[ 19 of 149] Compiling Paths_yi
[ 20 of 149] Compiling Yi.UI.Pango.Utils
[ 21 of 149] Compiling Yi.Monad
[ 22 of 149] Compiling Yi.Process
[ 23 of 149] Compiling Yi.Interact
[ 24 of 149] Compiling Yi.Window
[ 25 of 149] Compiling Yi.Tab
[ 26 of 149] Compiling Yi.String
[ 27 of 149] Compiling Yi.Syntax.Tree
[ 28 of 149] Compiling Yi.Syntax.OnlineTree
[ 29 of 149] Compiling Yi.Syntax.Driver
[ 30 of 149] Compiling Yi.Syntax.Haskell
[ 31 of 149] Compiling Yi.Syntax.Paren
[ 32 of 149] Compiling Yi.Syntax.Strokes.Haskell
[ 33 of 149] Compiling Yi.Syntax.Latex
[ 34 of 149] Compiling Yi.Syntax.JavaScript
src/library/Yi/Syntax/JavaScript.hs:121:10-25: Warning:
No explicit implementation for
‘uniplate’ and ‘emptyNode’
In the instance declaration for ‘IsTree Statement’
[ 35 of 149] Compiling Yi.Verifier.JavaScript
[ 36 of 149] Compiling Yi.Config.Misc
[ 37 of 149] Compiling Yi.Buffer.Implementation
...
```

Anyway, here are the good news:

]]>This is a short post revealing two little-known facts about two IRC-networks.

So, let’s say you need to find a channel on a large IRC network.

Turns out that on freenode, you can use convenient bot called Alis.

Let’s say, you want to find a channel about My Little Pony on freenode:

```
/msg alis list *pon* -min 10
/msg alis list *mlp* -min 10
```

where `-min 10`

means “has at least 10 users right now” and the rest is self-explanatory.

For an arbitrary large network that doesn’t have awesome bots, we can use an expect-script to `/LIST`

it and then grep the output. We will use telnet, so we’d like that network to operate in plain text mode.

Here’s my script:

```
#!/usr/bin/env expect
set ircNet [lindex $argv 0]
set ircPort [lindex $argv 1]
set nick "thelistbot"
set user "list 8 * : List Bot"
spawn telnet $ircNet $ircPort
sleep 3
send "NICK $nick\r\n"
sleep 1
send "USER $user\r\n"
sleep 1
send "LIST\r\n"
interact
```

then

```
ircNet="irc.oftc.net"
listIrc $ircNet 6667 | tee $ircNet.list
grep \#tor $ircNet.list
```

One must realize that `interact`

statement and sleep timings in my script are pretty arbitrary. The script, however, does what it should for most connections and most IRC servers.

Turns out, ung-dly service “gitter” has IRC backend. Still, it’s pretty awful: it drops messages when another client is connected to gitter with the same credentials, however it sorta works.

Here you can get instructions, written in ugly-backlit neon font.

as it turns out, as for now Gitter’s IRC backend is beyond unusable. Unlike in-browser client, this backend doesn’t shuffle messages randomly, neither have we observed it assigning authorship of a message to a wrong user. However, for large and active rooms, IRC backend proven to start dropping messages (not showing those at all) with no obvious pattern. And it doesn’t have anything to do with poor, if not lacking, multisession support of Gitter, problem persists even when we’re sure that no other sessions of the same user are initialized. I wouldn’t recommend using gitter for anything serious. (*Cough*, hello, webpack *cough*).

This post provides a list of the coolest articles and papers read by me during January 2015. Currently, this post is a work in progress.

This is a blog-post about using monoid to turn annotated binary tree into a data-structures-Swiss-army-knife. Main idea is that because often tag (annotation) of a branch is, practically, a function of annotations of its children:

```
annotation v a ∷ Tree v a → v
annotation (Branch _ x y) = f (annotation x) (annotation y)
annotation (Leaf _ a) = measure a
```

where `f`

fits axioms of `mappend`

and `v`

so often behaves like `Monoid`

, Apfelmus, citing Hinze, R. and Patterson, R. offers following generalization:

```
class Monoid v ⇒ Measured a v where
measure ∷ a → v
branch ∷ Monoid v ⇒ Tree v a → Tree v a → Tree v a
branch x y = Branch ((annotation x) ◇ (annotation y)) x y
leaf ∷ Measured a v ⇒ a → Tree v a
leaf a = Leaf (measure a) a
```

For practical uses, read the full article, it’s quite entertaining.

Luca is doing important job of covering grounds of interactive documentation for Nix package manager and NixOS.

Nix pills start with trivial stuff, like language overview and basic expressions and are taking reader to an entertaining ride through some specific parts of Nix workflows that might be obscure for a Nix newcomer.

The design of the blog is pretty terrible (see initial `callPackage`

definition in this post), but with w3m or lynx, it’s pretty readable.

A great post that boils down to the simple notion of choosing the right tool for the job, hinting the need of hiring experienced software architects and doing R&D properly (not following the hype).

Based on Volkov, N. 2013. Anonymous records. A solution to the problems of record-system. proposal, Nikita Volkov suggests using type-level string literals to build a library, capable of quite sexy things, like

```
type Person =
[r| {name ∷ String,
birthday ∷ {year ∷ Int, month ∷ Int, day ∷ Int},
country ∷ Country} |]
type Country =
[r| {name ∷ String,
language ∷ String} |]
person ∷ Person
person =
[r| {name = "Yuri Alekseyevich Gagarin",
birthday = {year = 1934, month = 3, day = 9},
country = {name = "Soviet Union", language = "Russian"}} |]
```

A subset of lens are integrated with Volkov’s records:

```
getPersonBirthdayYear ∷ Person → Int
getPersonBirthdayYear =
view ([l|birthday|] . [l|year|])
setPersonBirthdayYear ∷ Int → Person → Person
setPersonBirthdayYear =
set [l|birthday.year|]
```

There’s a long way to go for this library, but I really hope for a standard and sane records in Haskell.

That’s why you read maling lists, not wiki, people. Awesome article by Peter Simons, providing up-to-date information regarding setting up Haskell environment(s). Helped me to organize my environment.

Peter explains what haskellngPackages are, which problems they solve and why you should go to nixpkgs and mark stuff that doesn’t build as broken (at least).

Good article to read, to get a perspective of Haskell NG development.

FAQ about state of the art of Haskell NG and why should we care. Explains `provideOldHaskellAttributeNames`

, explains why did `ghc-wrapper`

disappear for good and much more. Prototype for new Nix Haskell documentation.

*Even though at the moment of writing I’m not sure if I can successfully build yesod and yi on my computer with nix, I have a clear picture of what I should do next. When I accomplish that, be sure that I’ll write a blog post about it.*

*Added, Jan 25th — turns out, haskellng is great for libraries that aren’t inherently broken (read: for major Haskell libraries and applications that don’t follow Yesod’s distribution pattern). Besides, Pete Simons is really fast on fixing bugs in haskellng expressions. I’m a little bit shy to send PRs myself yet though.*

In this post, Leo rolls out a Yesod-less grocery shopping listing application. What I love about this blog-post (and most of his blog-posts) is that it has this “get things done” attitude. Don’t expect production-grade code there, however it’s a very nice and gentle introduction into the world of WAI.

I found this article somewhat related to the talk, given by Paolini-Subramanya, M. at Erlang User Conference in 2013 (that I had an honour to witness in person). There Mahesh was talking about the practical sides of queue management and why in real high-load systems it’s absolutely critical to get less wrong. In that sense, some of theoretical insights given by Brandon.

The source code of this library is a nice study in queues, definitely worth looking at.

- Hoare’s Quotes (through AkkaRaceSample README).
- Two books about food and dietology (thanks, mkaito).
- Probability monad
- 31C3