Zero Conditional is used when we talk about general facts. Both parts of the conditional clause use “Present Simple” time.

If you finish the university, you become smarter.

If you study math, your logic skills become better.

You get a present if you write to Santa.

- The first type of First Conditional is used when we talk about possible events that may possibly happen. “if” clause uses “Present Simple” time, and “main” clause uses “Future Indefinite” time.

If I have enough time, I will study math.

If I have a working visa, I will start to work in Germany.

I will walk around the lake if I write a post in my blog.

b. The second type of First Conditional is used when we talk about events that unlikely happen. “if” clause uses “should + infinitive” and “main” clause uses “Future Indefinite” time.

If I should have enough time, I will study category theory.

If I shouldn’t have a working visa, I will finish the “How to prove it” book till July.

I will start to work on “Verified Functional Programming in Agda” if I should finish the “How to prove it” book.

Second Conditional is used when we talk about an unreal event in the present time. “if” clause uses “Past Simple” time and “main” clause uses “would + infinitive”.

If I had enough time, I would study Japanese.

If I could surf, I would fly to Australia.

I would become rich if I won a lottery.

Third Conditional is used when we talk about an *absolutely* unreal event in the past. “if” clause uses “Past Perfect Subjunctive” and “main” clause uses “would + Perfect infinitive”.

If I had had enough time, I would have studied math last year.

If I had written a post in my blog, I would have walked around the lake yesterday.

I would have bought the island in the Pacific Ocean last year if I had won the national lottery.

- “if” clause is in the past and “main” clause is in the present or future.

If you had run a marathon last year, you would feel better now.

If I had written a post in my blog, I would be walking around the lake now.

I would be rich now if I had won a lottery yesterday.

b. “if” clause doesn’t have a specific time and “main” clause is in the past.

If she wasn’t so smart, she would not have passed her exam.

If I wasn’t so brave, I wouldn’t have jumped with a parachute.

She would have passed her exam if she hadn’t been so stupid.

1min 44sec read

]]>I finished chapter three. The solutions of the exercises can be found here: htp_3.pdf. I am on the second section of the “Relations” chapter.

After finishing the “How to prove it” book I want to work on the “Verified Functional Programming in Agda” book. Some knowledge of Agda may help me to become a better programmer.

My family had to travel to Warsaw for a few days. Here is one shot from there:

I tempted to think it’s the main reason why I walked only 27 kilometers. Even if I walked only 27 kilometers it was enough time to finish listening to my second audiobook − “A Wild Sheep Chase”. I started to listen to another book that called “Hard to Be a God” by Arkady and Boris Strugatsky. It’s really cool that I do sports activity in conjunction with listening fiction books.

I listen to the really nice talk from “The Haskell Cast” series: Episode 13 - John Wiegley on Categories and Compilers.

I played with “Programming with bananas and barbed wire. Part 1” tutorial; pretty cool introduction to recursion schemes.

I am going to walk 42 kilometers.

I am going to finish sections two *and* three of the “Relations” chapter.

50sec read

]]>I want to start from the goals for the week. I have set them in the previous week.

- Solve all exercises from the chapter three of “How to prove it” book.

I was pretty sure that I will finish the biggest chapter on this week (biggest chapter so far). The amount of the exercises to solve in this week was much fewer than in the previous week. However, now I know that the amount of something shouldn’t be the main factor of estimation. Since exercises may have a different level of difficulty, and that’s the case for this week.

Last three exercises of chapter three remain to solve for the near future. In general, I satisfied with the results of the goal.

- I should walk on 40 kilometers.

Every person with an aim to be successful should devote part of the life to the sport. Walking on 40 kilometers per week is hard to call a sport, as maximum, a physical activity. However, I really like walking and, I think, this is my first step towards running for long distance and, potentially, towards the marathon run (my long term goal).

I walked around 30 kilometers. I listened more than half of “Охота на овец” audiobook during walking. I found the place in my life for the fiction books!

As a retrospective, I need to track the number of kilometers more precisely and walk *at least* 40 kilometers per week (don’t skip rainy days, no excuses!).

- I should practice English and book the lesson.

English is the main language in the world in this century. English is the really important thing in Software Engineer career, I should try to improve the language skills as much as possible.

I didn’t book the lesson in the week (shame on me!), but I am going to do it in the near future, really!

One positive thing, I hope this blog should improve my writing skills in the long run.

I have the idea to implement typos, errors reporter tool for my blog. Initially, the idea is not mine, of course, but the existed free tools don’t satisfy my needs. Briefly, the idea: a user selects specific text with the typo or error, clicks “Bug” button, optionally writes a comment, and I receive the email with an information that somebody found an error on my page. Error reporting should be UX friendly and very simple, *simpler* than using regular comments otherwise, this whole idea becomes useless. I even feel that I am capable of implementing it without any troublesome. Only one thing which stops me from implementing it is the time and priorities. My main priority on the technical side is “How to prove it” book for now.

That’s pretty much all about the weekly goals analysis. I satisfied with my performance in general. But, of course, there is a room for improvements.

*Music*:

It looks like my music search is over at least up to next month. I mostly listen to a smooth jazz, such bands as Acoustic Alchemy, The Rippingtons, Fourplay, 3rd Force. I also like The Down To The Bone, Tangerine Dream, The Rolling Stones, John Coltrane, Mozart.

*Youtube*:

I watched a nice video from Bartosz Milewski about arrows. I recommend it to everyone interested in Haskell and Category Theory.

*Math*:

https://en.wikipedia.org/wiki/Drinker_paradox

*Eng*:

I found a nice resource for practicing the English grammar: https://www.englishgrammar101.com.

I want to work on it in the near future.

- Finish three last exercises of chapter three and start to work on chapter four (the chapter about math relation).
- Book a lesson with a professional English teacher.
- Walk on 40 kilometers.

The goals are pretty much the same as for the previous week. Good luck!

2min 24sec read

]]>“How to prove it“

I didn’t manage to finish the exercises in chapter three. However, I am not sad. Guess, why? Because I learned how to make the proofs, which is the main purpose of this chapter and the whole book, I think.

I am at the end of the fifth section of the chapter. The chapter has seven sections. Sections six and seven have fewer exercises then three and four, so I feel that I’ll finish the chapter on this week. Fingers crossed.I found a new interesting activity, which is also useful. I do a long distance walking (well, if seven km is a long distance) and listen to an audiobook. So, on this week I walked around 40 km and finished to listen “О чём я говорю, когда говорю о беге”. Pretty nice book. After listening to the book, I felt the desire to run a marathon distance, I wish to do it at some point in the future.

Next book for my walking activity is written by the same author: “Охота на овец”.The interesting talk about the extended functor family:

George Wilson − The Extended Functor FamilyHandy one-liner bash, the command which joins the images. This is from ImageMagick software.

`convert input1.png input2.png input3.png -append output.png`

`-append`

join the images vertically

`+append`

join the images horizontally- Some music which I listen during the week:
- Acoustic Alchemy: all discography.
- Tangerine Dream: Le Parc, Melrose, Rockoon, Tiger.
- The Rolling Stones: Beggars Banquet.

- third chapter of “How to prove it” book is done
- 40 km of walking activity
- take an English lesson

1min 6sec read

]]>*“How to prove it”*:

I am working on the exercises for the 4th section of “Proofs” chapter (chapter 3). The chapter is quite big (it has 7 sections) and I think it will take one more week to finish the chapter. “Proofs” chapter obviously teaches how to make proofs of statements using specific techniques. In the 1st section, the author describes basic proof strategies, like how to proof a conclusion of the form*P*→*Q*. In the 2nd section, he adds the proofs involving negations and conditionals. The 3d section introduces proofs involving quantifiers and 4th section adds proofs involving conjunctions and biconditionals. The chapter has quite a lot of exercises which can be solved using “Proof Designer” application and I like it, since using the Proof designer, you don’t need to type a lot of characters and the program checks your correctness. Thus, I can be sure that I did a proof correctly which is quite important for my confidence. That’s all about the book, I’ll publish the solutions which definitely should have some errors when I finish the chapter 3.*Emacs*:

I started to use*again*the centered-window-mode and I quite like it: now my eyes instead of looking mostly on the corner of display look at center.*Nice browser extension*:

A browser extension that turns package/module names on Github into links (Chrome only): module-linker*Future in Rust*:

I have read this post: http://aturon.github.io/blog/2016/08/11/futures/ and looked at the implementation of “Future” feature, quite interesting stuff: the purpose is similar to javascript promises, but an implementation is completely different. The future code compiles down to an actual state machine which progresses via callbacks (with no overhead).*Lenses in practice*:

Enjoyed watching this video: John Wiegley: Putting Lenses to Work. Especially last part of the video with advanced examples.*Music*:

Suddenly I started to listen new to me genres of music: Downtempo, French House, lounge music, Future Jazz.

These albums play in my player:Stephane Pompougnac − Hotel Costes

John Beltran − Americano

Minus 8 − Minuit

Parov Stelar − The Princess

- I
*hope*to finish the chapter 3. - Need to book the English lesson on this week and prepare for the lesson by making the essay.

1min 32sec read

]]>I finished to work through the “Quantificational Logic” chapter (chapter 2) and did the all exercises here: 2.pdf. It doesn’t mean that I did the all exercises correctly, so feel free to create an issue and submit a pull request on GitHub for improving the solutions.

One year ago I was writing the tests using SmallCheck and had a hard time understanding quantifiers. Finally, after finishing the chapter 2 I understood what does it mean universal (∀) and existential (∃) quantifiers and how to use them. Now, looking at the SmallCheck documentation doesn’t scare me at all and even makes perfect sense!

Moreover, chapter 2 describes such things as the family of sets ℱ, the union of the family of sets ∪ℱ, the intersection of the family of sets ∩ℱ, the power set 𝒫(*A*) and much more.

I already started to work through “Proofs” (chapter 3) and even finished first 2 sections of the chapter. However, the chapter has 7 sections (the longest chapter so far and I think it’s the core chapter of the book). So, I have ambitious plans to finish the chapter 3. I only 104 exercises away! Some of these exercises can be solved using the Proof designer. It’s the small program which author of the book suggests for proving things.

I need to do the exercise for my English classes and write the small essay about world overpopulation.

1min 2sec read

]]>The only way to learn mathematics is to do mathematics.

— Paul Halmos

I decided to spend a month or so on improving my math skills. I understand that “How to Prove It: A Structured Approach” book by Daniel J. Velleman is not a silver bullet and may give me only the basics. Hopefully, it’ll help me to understand deeper the Category Theory II videos and prepare for Software Foundations course which I have a plan to do at some point.

I’d like to do exercises from the book as many as possible, so here are my solutions for all exercises from the first chapter: 1.pdf.

I plan to do exercises from the second chapter of the book.

If a friend of mine prepares the backend for “Highlighting” feature in Heutagogy project I may switch to the implementation of “Highlighting” on mobile.

32sec read

]]>**Microkernel**

I went through series of articles on building simple OS kernel. I really suggest these articles to everyone who wants to get familiar with “bare metal” programming.

Starting point: Writing a Simple OS Kernel — Part 1**Annotations**

I started to implement annotation for Heutagogy project, so a user can extract important pieces of information from the text and save it for reviewing later. One important thing to mention: I did few hours of*remote pair programming*, it was nice.**Category Theory**

I started to watch videos from Category Theory II. It’s quite interesting but I decided to postpone watching these videos for a few month.**Plotting**

Gnuplot is a tool for plotting simple charts. I started to use it for plotting “Review pomodoros” chart.**Lens**

I worked through “Lens: a Swiss Army knife for data structures” article from not published*yet*Haskell book. Here’s the article on the same topic from the same author: Lens over tea.**How to prove it**

I decided to work on “How to prove it” book. It should open the door for type theory and category theory books. Since I want to do exercises from the book I started to use TeX in emacs. TeX is cool and not scary at all, try it if you need to write math formulas.**Secure shell**

I connected to the laptop via phone and disabled/enabled keyboard/mouse just for fun. I used Termux on mobile.**Sticky keys**

I found a nice xkbset tool which helped me to enable mouse keys (pressing key emulates mouse click) permanently and sticky keys. However, I am still evaluating sticky feature since sometimes it’s inconvenient to have all sticky keys, I’d like to restrict it only to the Shift keys, but it looks like it’s not possible with this tool.

- finish implementing annotations for android app
- start implementing annotations for chrome extension
- continue working on “How to prove it” book

1min 33sec read

]]>*What is functional programming?*

A style of building programs using mathematical functions.

*What is mathematical function?*

A relation exists between a set of inputs and a set of outputs; each with the property that each input is related to *exactly one* output.

Let me give an example:

```
var x = 1;
function impure(y) {
x = x + y;
return x;
}
function pure(x) {
return x + 1;
}
console.log(impure(3)); // 4
console.log(impure(3)); // 7
console.log(pure(3)); // 4
console.log(pure(3)); // 4
```

Impure functions return different result for the same input (number `3`

). In other words − impure functions have side-effects.

*Why is this bad?*

Because you lose modularity and it is harder to think about functions with side-effects.

On the other hand, it’s really easy to compose pure functions:

```
function compose(f,g) {
return function(x) {
return f(g(x));
}
}
function plusOne(x) {
return x + 1;
}
var plusTwo = compose(plusOne, plusOne);
var plusThree = compose(plusTwo, plusOne);
console.log(plusOne(1)); // 2
console.log(plusTwo(1)); // 3
console.log(plusThree(1)); // 4
```

It’s like *lego* games; by having a set of pure functions you can easily build your own galaxy.

*Why aren’t pure functions used all the time?*

Pure functions are awesome but the real life programs have a bunch of side-effects. Getting a response from the server, reading from the file, printing to the screen − all these operations have side-effects. You can’t build a truly *useful* program just on top of pure functions − you need functions with side-effects as well.

Haskell has a smart way to distinguish between pure and impure functions. It is common in the Haskell community to write function types for the functions.

```
makeApple :: Seed → IO Apple
makeJuice :: Apple → Juice
```

If you see `IO`

(it’s a Monad) somewhere in type signature, it means the function is impure.

As well, Haskell has strong static typing. Before running a program, compiler should correctly type check a program (and compiler can catch a dozens of errors!).

Now, let me highlight some parts from Don Stewart’s talk. Don Stewart leads the Haskell teams in the financial sector. In his talk, he shared how to control complexity of applications with more than **3** million lines of code.

Here are a few tips from him:

• Types help to control complexity.

• Compare 2 pricing functions:

```
f :: Double → Double → String → Double
g :: Rate Libor → Spot SGD → Date → Rate SIBOR
```

`g`

has more expressive types. In other words, you can say more about the function by looking in function type assuming you know financial domain.

• Remove unclear types.

• No side effects. Instead, try to write pure functions as many as possible.

• Make things simpler by controlling `IO`

and new types.

• Types are for keeping code maintainable and self-documented.

• Use “new types” and “data” to distinguish unique entities in the system.

• Using Phantom types, you can tag the things. Make it impossible to mix up or combine values in nonsense ways.

• As opposed to `Stings`

and `Double`

types have too many valid values for most use cases, `Bool`

often has too little information.

Instead of `authenticate :: String -> String -> Bool`

write `authenticate :: Privileges p => User -> Password -> IO (AuthUser p)`

• Lift errors into types (using `Maybe`

and `Either`

) for making functions modular.

• Move partial functions to the edges and write total functions as a core of program.

• Types − in order to minimize complexity; it helps to deliver faster. Reuse is extremely cheap.

Of course, for the reader unfamiliar with Haskell, these tips don’t tell much, but let me repeat once more. Basically, the main idea is that you need to use meaningful types as much as possible. In such a way you give a compiler more information about a program and consequently, the compiler helps to catch a lot of errors and hopefully optimize the code. Other simple ideas are to use total functions, move side-effects to the edges of a program. That’s it!

Even if Haskell has a great community with a lot of academic folks behind it, the community is really small compare to the Python or Javascript, or Php communities. It tends to lack some useful libraries, so if you switch to Haskell you should expect to have to contribute a lot to existing libraries or write more libraries for your needs. However, I believe it should be changed soon since a lot of people have realized that the OOP paradigm is not an answer to robust software development, especially in the time when parallel and concurrent programming plays more important role. I understand that re-writing back-end systems on Haskell, if you were building the systems during last 10 years using Javasript, Php, Java may not be an option. As a first step towards Haskell I suggest a “Haskell-like” language − Elm. Why Elm? Elm looks a bit simpler to start and it’s web-browser-based, and so it looks like a good alternative to almighty Javascipt. One more advantage of Elm is that you can introduce it gradually into an existing JS project^{1}. Once you are happy with your front-end using Elm you may think to move some of your back-end services to Haskell. After Elm it should be much easier to start.

Happy hacking!

At the end of this post I’d like to share a photo with one of the core Haskell developers, Simon Peyton Jones.

3min 51sec read