using Programming;

A Blog about some of the intrinsics related to programming and how one can get the best out of various languages.

Getting started with programming and getting absolutely nowhere (Part 1)

How to become a programmer (in a few not-so-easy steps)

Lesson 2: Now That We're Programmers, Let's Make Something

Recently a friend of mine has asked me to teach him "how to become a programmer", which is not really an easy task to accomplish, but I'll give it a shot. Since I'm an altruistic person, I am going to make this a series of blog posts on the idea of becoming a programmer, we're going to mostly look at the .NET structure, and the first few lessons will be in F# to get the ball rolling somewhat quickly.

The first rule of programming: forget what you think you know

All programmers, including myself, start somewhere. The biggest mistake I've made on the quest to become a programmer is to focus entirely on some "bigger goal" to achieve, some large project that I wanted to build or work on. Goals are great, but we have to start small. (Especially in the modern world, where we have hundreds of languages and frameworks and environments to choose from.)

So my very first word of wisdom is to forget everything you think you know. All of it. Forget what languages you think you want to learn, forget what areas you want to work in, forget what you know about "HTML coding for Myspace pages", ditch it all. We're going to start your career of programming from the beginning - the basics first, then we'll work up to the fun things.

"Hello World" is so cliche

I'm not going to bore you by starting our adventure with a "Hello World" program, instead we're going to start it from an actual business-driven design. Instead of contriving highly-egregious examples of programs to write, building some sort of "example" application, we're going to build real-world business applications: things that you will actually be expected to come up with. And we're going to do so poorly, so that we can learn where to improve. I'm going to take personal experiences (and mistakes) and burn them into your core, so that you can identify what makes good code good, and what makes bad code bad.

The first mistake is that people always lose interest, as you probably have by this point in this blog post. But hang tight, we have some code coming up, and I'm going to start showing you how we can take some basic, elementary ideas and turn them into truly remarkable pieces of software.

Without further ado, let's get going

We're going to begin our entourage into programming with F#, which is very much unusual from normal adventures. The easiest way to get started is to install a copy of Visual Studio 2017 Community (or if you prefer to purchase it, Enterprise or Pro), with the F# development tools selected. I'm not going to walk you through this for a few reasons:

  1. There are about a hundred thousand articles and blog posts on installing Visual Studio and adding and removing features.
  2. It's actually extremely self-explanatory, it really is pretty simple to get set up.
  3. I want you to struggle a bit with this.

Notice point 3: I'm not going to hold your hand, we're going to go on an adventure and we're all going to make mistakes, I want you to struggle with this entire venture, for two reasons on it's own:

  1. Only by struggling do you force yourself to think critically;
  2. I want you to decide if this is a path you wish to pursue.

Too many people say "teach me to be a great programmer" but refuse to put the work in to become one - I can't write a long, wordy article that makes you a good programmer, I can only guide you down the path to success. It is up to you to decide if you wish to continue down the path or not. By forcing you to struggle with real-world problems you'll be better prepared for how programming actually is.

So let's start with some code. Because we're using F# it's going to be a somewhat quick foray into our career, so open up Visual Studio, and find the F# Interactive window - I won't tell you where it is, so this is the first struggle you'll have to do on your own. (I'll give you a hint - it's under some sort of "Window" menu somewhere.)

Once we've opened F# Interactive, I want you to define some sort of "domain model" to describe some sort of arbitrary user. The F# syntax for such a thing is something like:

type SomeName = {

The syntax for SomeProperty can look something like:

SomeValue : SomeType

Right, so I'll give you the first object for free:

type User = {
    Id : int
    Name : string
    Email : string
    Phone : string option

For those of you who don't know, this is the basic F# syntax for defining a "class", but we get a lot more than just a class, so we won't call it such a thing (because naming is important - if it's not a duck we really ought not call it a duck). In F# this is called a Record.

A Record in F# has a few basic features: properties/fields, values, and is non-nullable. In fact, almost everything in F# is non-nullable which is why we're starting with this language. Nullable values are hard, and if you don't believe me just "Google" for a "NullReferenceException" - it should become clear.

What we've define here is a "User" with four properties: an "Id" (which is an integer: a whole number so-to-speak), a "Name" (which is a string, or a sequence of characters in a specific order), an "Email" (which is also a string), and a "Phone" (which is a string, but it's "optional" - we may or may not have a phone defined). An "option" in F# is a kind of null, but not really. It has two cases: a None value (which means the lack of a value entirely), or a Some value, which means that there is "Some" value there. These are important because these idiomatically represent the idea of a non-existent value.

One of my favourite features of F# is it's type-inference, that is, F# will detect what types you're playing with in most situations correctly. So we're going to define a "User" now, the syntax of which is:

let myUser = {
    Id = 1
    Name = "Elliott"
    Email = ""
    Phone = None

I believe I owe you an explanation: by specifying all four of these properties, F# understands that we want to create a User object. We didn't explicitly tell it that, but it assumed based on what we gave it that we wanted that type of object. We could have also told it that we wanted myUser to be a User with a type-annotation, that is, : SomeType, which would mean let myUser : User = {...} would create our myUser record. Simple, right?

Pointing out our First Mistake

I need to tell you that we already made a few mistakes here, not the least of which is the choice of myUser as a name. What does myUser mean? Why does it have the type-name in it? What will myUser be doing?

We really need to touch on naming, but I don't have a lot of time for that, so I'll be brief: naming things is hard. You should name something for what it means, rather than what it is. That is, instead of myUser, we should really name that ebrown, or something.

We also need to touch on the type-safety (which is one of many such safeties) in F#. As a language, F# forces you to define the entirety of a type at once. We know that Phone has a value of None, which happens to be the default, but we still have to tell F# that we want to set None explicitly to Phone. It won't do it by itself, we have to. Remove that line and you'll see what I'm talking about.

So what have we effectively done here? We've created a Type, but what is a type? What does it do? To put it short, we've created a point that we can hold data. So that's a good thing, right? We've created something that can store state, something that holds a group of related values. We could have just as easily done

let ebrownId = 1
let ebrownName = "Elliott"
let ebrownEmail = ""
let ebrownPhone = None

So what's the difference? Why did we build a type? I'll give you a hint: what stops you from sending ebrownId, ebrownName, alexEmail, ralphPhone to a method? Ah, that's what it's for. It groups related values together so they're unmistakeably related. They belong in a group.

Alright, so I've done a lot of talking (see: rambling), and we've effectively seen what, 20 lines of code? Let's actually make something happen. I'm not going to explain every little detail of this next snippet, but I will go over the general idea.

type User = {
    Id : int
    Name : string
    Email : string
    Phone : string option

let ebrown = {
    Id = 1
    Name = "Elliott"
    Email = ""
    Phone = None

let createReminder thing user =
    sprintf "Hello %s, this is a reminder to do the thing (%s)." user.Name thing

let remind =
    createReminder "Write a Blog Post" >> printfn "%s"

let reminder =
    ebrown |> remind

Right, so what happened? This is actually pretty simple, we already saw creating a user, now all we're adding is passing that user to a function and gathering a result. There are a couple key points to note here:

The pipe-right (|>) operator takes the value on the left side, and transforms it to be the last argument of the function on the right side. So ebrown |> remind is the same as remind ebrown. We use this pipe-right operator mostly to keep the order of things consistent. I.e. let someResult = someValue |> step1 |> step2 |> step3, thus allowing us to follow the "flow" of the functions.

The next notable piece is the compose-right (>>) operator, this has a similar effect as the pipe-right, except that instead of needing a value, it needs a function. So it builds a function that is composed of the steps of the first function, then the second function. This can also be chained as necessary, the difference between this and pipe-right being what they operate on: pipe-right operates on the value, compose-right operates on the function.

This brings us to an interesting aspect of F#: the type system. I've deliberately avoided discussing it yet, but now it's about time to get into the nitty-gritty of what the type-system does.

In most "regular" languages functions are presented as some type of prototype: you have an input and a result. This is usually written (in C-based languages) as ResultTypeName FunctionName(InputTypeName1 inputValue1, InputTypeName2 inputValue2, ...), etc., which basically says "this function takes [...] as input and returns a ....".

In F# we do things a little differently. Instead of declaring a function as having "all these" inputs each and every function in F# has exactly one input.

But Elliott, our createReminder takes two parameters, a thing and a user.

Technically, this is wrong. The createReminder function takes one input, then a new function is created which takes the second input. We call this "currying", in laymans terms it means that functions are partially applied, which is, kind of, part of the point of being a functional language.

Type Definitions aren't so scary

Enough blab, let's talk about a type definition. F# defines a function as 'a -> 'b, that is, 'a is an input which returns a 'b. If you look at the signature for our createReminder, you'll see that it is string -> User -> string, "I first take a string, which returns a function that takes a User, which returns a string."

If you look at remind, you'll see a very different signature: User -> unit. In F# the unit is the "void" type, that is, a unit is a nothing. It's basically the end of something. You can create a unit directly as (). If you run let unitThing = () in F# Interactive, you'll see it prints val unitThing : unit = (), meaning it's a nothing. So remind takes a User and returns a "nothing".

So, all this said, we can build a reasonable thought process from the following signatures:

string -> int -> unit            // Takes a string, then an int, returns a unit / nothing
string -> string -> string       // Takes a string, then a string, returns a string
int -> (string -> int) -> unit   // Takes a string, then a `string -> int` function, returns a nothing
(string -> int) -> float         // Takes a `string -> int` function, returns a float

Do those make sense? Good, I hope you thought that was easy, because I'm only going to make things more difficult from here.

What the snot does any of this do?

I want to intentionally confuse you for a moment, because learning requires a struggle. We're going to look at a highly contrived example (remember when I said I wouldn't do that? I'm breaking that rule apparently) of just how complex we can get.

let formula values =
    let xb =
        |> List.sum
        |> (/)
        <| (values.Length |> float)
    |> List.fold (fun acc x -> acc + (x - xb) * (x - xb)) 0.
    |> (/)
    <| (values.Length |> float) - 1.
    |> System.Math.Sqrt

Oh boy. This looks fun. Can anyone guess what's going on here? If you guessed this calculates the sample-standard deviation, you're spot on. We simply let xb be the average (calculated by summing the values, then divide by the length), then we simple "fold" over the values, summing the squares of x - xBar together, divide by N - 1 and then take the square-root.

You should have been able to guess that the pipe-left (<|) operator does what the pipe-right operator does, but in reverse. Instead of supplying the right side as the last argument to the left call, it supplies the left side as the last argument to the right call. Do note that nothing is special about the division (/) operator, we can actually treat operators as functions in F#. That is the biggest take-away from this.

We'll also notice this function has a type-definition of float list -> float.

Building an order of elements

I'm going to keep on the boring train for the rest of this section, since we're already there. (My rambling doesn't help.) We're going to discuss greating a list/array/sequence. (All three of these are different ways to represent a grouping of values that share a type.)

The most basic of these types is an Array, which is also an array and a []. All three of these are valid ways to state "array". Arrays are one of the most basic "collection" structures. Essentially, you declare an array (of a fixed size) and then set elements in it by "index" (0-based). In F# we access an array element by .[#], where # is the index (with the first being index 0) of the element we want.

Think of an array as a crayon box: you have a specific number of crayons (each of a different color) which you can access by "index" (or position). Simple, right? We could even represent a crayon box in F#:

let crayons : System.Drawing.Color array = ...

Pretty simple. You can construct an array of elements by wrapping them in [|...|], and separating each element by a semicolon. ([|System.Drawing.Color.Black; System.Drawing.Color.Gray; ...|]).

Next is a List or list. This is simply an Array that can be resized. The syntax is [...], with the same semicolon separator.

Finally, a sequence. This is a very special collection in that it's lazy. The syntax is {...} with the semi-colon separator. The thing about a Sequence (or seq) is that it doesn't initiate all the values initially, it only initiates them when you iterate them. (That is, ask for the next value.) While a list and array both allow you to index a value, a sequence does not. Remember this, because we'll need them later.

I'm going to stop here, but I'm going to pick up where I stopped here tomorrow, and we'll go over a couple business domain issues and learn how to build software to represent them. I'll be doing a lot of "here's how you solve the problem, each step of the code" and not a lot of "this is what _ means", so I expect you to research the different operations that we do, and try and use some critical thinking to push yourself to learn what's going on.

I do realize that this was probably the worst possible writing ever by me, but it's been a while since I've done one of these and I tried to just cover what I could as I thought of it. The next few sections of the series will get a lot more informative and organized.