A Sort of Prologue (Basic Setup First)

“There are three types of analphabets these days. Those who can’t read or write; those who can’t speak English; and those who can’t use a computer”. After I heard those words, I kept thinking how they apply to me: I could read and write pretty well, I even was starting a second major in literature. My English, on the other hand, was very poor. I could read and write, but my understanding was very limited and my speaking was close to none. What about computers? They were a sort of typewriters with screen. They have a browser and some applications to practice listening. But I didn’t know much about them. I only knew how to use the applications that I really needed.

I was an analphabet.

But I was an analphabet with a plan: I was studying English in the British
Council and I was planning to go to Canada as soon as I completed my bachelor degree.

But again, what about computers? I was interested in creating my own web page. So, the first step was to go to AltaVista (Google didn’t exist yet) and download an HTML tutorial. Along with HTML came a little of CSS and some drops of JavaScript.

After I created my ugly, table based designed web page, I felt I wanted to learn more. I wanted to learn programming. Real programming. And I found C, and C brought me to Linux; and Linux brought me to Red Hat; and Red Hat made me discovered Python; and Python brought me to Django. And from discovery to discovery, in a slow and long path, I became a programmer.

But I don’t want to talk about those fragments of my life in these memoirs. I may remember and mention briefly those experiences. What I want to do on these pages is to talk about how I am becoming a software engineer. And I started becoming a software engineering after I started working as
a web developer in a start-up company in Japan.

I will slow down in this part of the story as it will allow me to go over the first big subject I want to talk: the development environment.

Learning Languages (Basic Setup First)

When I started working as a web developer, I neither use python nor C. I used
Ruby. The company used Ruby on Rails to develop the backend of its first two products. The frontend was build on React using TypeScript. The new product was being developed using Elixir.

That means that I had to learn a new language. To learn it, I did what I have
done before: get a book, perhaps a tutorial, and start reading and writing code. Soon after I found the usual problems: the book uses a different version from the one that is installed in the machine, the tutorial doesn’t touch unit testing at all, the code doesn’t run.

I did learn Ruby, Rails and Ruby on Rails. My first assignment was to modify the application to read data from a new API rather than from MySQL. But after those couple of months, I was asked to learn Elixir.

By then, I knew that a big part of working as a developer is learning new technologies: new languages, new libraries, new services, etc. So I started thinking how to learn a language in the most effective and practical way. Books and tutorials didn’t work. Books on programming languages have a short life span. Books on specific frameworks die even faster. Although the basics remain the same, the libraries are constantly changing, new keywords are added, changed, removed, the focus of the books get outdated.

I thought it would be better to focus on learning the basics of programming, have a learning framework to quickly adapt to a new language and to quickly be able to write quality code. After all, languages doesn’t differ that much from each other. A person who learn one language in each paradigm, can learn and be good at any other language. This is so because the basics are present in any language. Thus, having a good, solid grasp of these basics concepts should be the goal of any programmer. At least, it was my goal when I start learning elixir.

Another reason why I started finding books on programming languages impractical was the way the material is thought. Trying to start from the basics, they jump to the REPL (Read, Eval, Print Loop) and start writing statements. Although the REPL may be useful sometimes, it is rarely used when programming professionally.

In the real world, programmers use build tools to create, test and build
projects. Teaching how these tools work for a language should be the first
step in teaching (and learning) a new language. If you are not able to run
what you write, the fun of the language is gone. This put me off from learning
Java and learning JavaScript properly. It was not until node appears that I
enjoyed writing JavaScript. It wasn’t until I found gradle that my dislike
for Java disappeared.

So, in my imaginary programming language learning framework, the first step is to learn how to set up the building tool.

The Programming Environment.

Let's write some code in these memoirs! Let's make them practical! For that, I will use Haskell for the code samples. Then, let’s explain the building tool for Haskell before returning to the anecdote.

For Haskell, the build tool is called Stack. It is not the only one. It is even built on top of another older application called Cabal. I never learned Cabal; I jump into Stack directly.

The instructions to install `stack` are in its home page, it is just a quick `curl` command:

curl -sSL https://get.haskellstack.org/ | sh

Stack has commands to create a new project:

stack new rayuela

Set up the compiler and other needed packages:

stack setup

Build and run the executable:

stack build
stack exec rayuela-exe

And Stack also has a command for testing. But before we can test anything, we need to add the testing library to the dependencies. The dependencies are kept in a file called package.yaml. Here, we look for the tests section and add hspec:

There are other libraries in Haskell that provide a solid testing framework, but I like hspec, and it is the one I will be using for these projects and these series of articles.

To run the test, we use:

stack test

Haskell

The anecdote will end this first part.

It was during a manager’s training day when someone suggested me to learn Haskell. I can remember the conference room when the training was giving, I remember the trainers that came from Singapore for the two weeks of training, and I also remember many of the managers in APAC that were in Brisbane for those two weeks. But I can’t remember why I was suggested to learn Haskell. I guess somehow we start talking about programming, then jump to programming paradigms, functional programming may have come afterwards and finally Haskell.

The suggestion was heard but not act upon. It wasn’t until I went back to Australia for the wedding of my best friend that I took action. I asked
for a month holiday and decided to read Learn You Haskell for Great Good. I had already used Elixir and, since then, I was really interested in functional programming. This interest made the suggestion from way back came to my mind over and over again. I had to learn Haskell.

I read Learn You Haskell for Great Good without writing any code. I read it
just for pleasure and pleasure I had. It is a great book to read and the book that open my love for Haskell. The simple syntax and the type system was something I never encounter before. The type system was perhaps the catalyst that shift my mind from a procedural way of thinking to a computational one. But I will think on this shift on the next couple of article, along types and functions and design templates.

Haskell has become my favorite language and the one I will be using to make these memoirs more practical to any reader. But I believe Haskell is a great language to learn even if you don’t have the opportunity to use it in the industry. Haskell will help you understand types. Indeed, Haskell data types will help me later on, perhaps in the next article, when I start talking about data declarations, design templates and how to design with functions and data.

Perhaps it is time to stop now. Enough for now. Rest dear reader and then go to the next article on designing functions.