### Channel Your Inner Gopher

Channeling your Inner Gopher - (Literally) Reflecting upon Channels Many gophers are likely familiar with the communication paradigm, channels. An elegant solution to communicate (uni or bidirectionally) typed information among go-routines. In it’s simplest form, we declare as type-valued channel variable, make it, and then send and receive data through it. Easy enough! package main import ( "fmt" ) func main() { var simpleChan chan int = make(chan int) go func(c chan int) { // send important data to the channel c <- 42 close(c) }(simpleChan) // receive data num := <-simpleChan fmt. Continue reading### Once Upon a Reflection: Looking Deeper into Golang reflection

I often reflect upon my code… One of the coolest features of the Golang programming language is the reflect package. As the package documentation states at the onset of the package: Package reflect implements run-time reflection, allowing a program to manipulate objects with arbitrary types. The typical use is to take a value with static type interface{} and extract its dynamic type information by calling TypeOf, which returns a Type. Continue reading### Go Get Interfaced: Enums in Golang

Golang, Interfaces, and Enums So here’s a nice golang idiom that I ran across years ago that I found generally useful. Golang, unlike languages like c doesn’t natively support enumerations. Instead, constants typically are used when creating a list of enumerations. But, go is a strongly-typed language, so we can do better than simply using constants - we can type our enumeration with the use of a type declaration. type DogState uint By defining a type for our enumeration, we can consistently pass and return typed-values among our functions operating on our enumeration. Continue reading### Gogo

Here we gogo! Years ago, I wrote an interesting article that I thought might be worth re-posting (and revising) here on my blog. For a while I got into programming in golang and in the early going (pun-alert!), there were a lot of idioms that were not well understood by a noob. One of those paradigms was channels, go-routines, and signals used simultaneously. Taken separately, they are more easily understood. But when taken together, there can be some confusion. Continue reading### Recursion Revisited

### Recursion, from more than one point-of-view.

A common programming idiom in computer science is solving a problem by self-reference, also known as recursion. In this post, we look at two different implementations of the same problem.

#### Solve a recursive problem in two different programming language paradigms

Let’s look at the solution to a simple problem, compute $f(x)=e^{x}$.

We will illustrate two separate solutions - one in a procedural language (python), and the other in a functional language (elixir).

Let’s start off with the functional language. Were does recursion come into play?

We define the function $f(x)=e^x$ as the infinite sum, $\text{ }f(x) = \sum_{n=0}^\infty{\frac{x^n}{n!}}$

In our solution below, we define two separate recursive functions, `exp/2`

and `fac/1`

. What’s interesting to note here is how each of these functions has two separate definitions. This is an aspect of programming in elixir that elegantly uses pattern-matching to return different results depending upon the input. Our two functions nicely dovetail into the base-case and recursive case of a recursive algorithm.

For example, looking at `exp/2`

, the first function definition returns 1 for any value of x (as indicated by the `_`

preceding the variable) and returns 1. This is the mathematical equivalent of $x^0=1\text{ for any }x$.

The second definition of `exp/2`

is the recursive case. for any value of $n\gt0$. Moreover, we define `exp(x, n)`

as $\frac{e^x}{n!}$ + `exp(x, n-1)`

.

Similarly for the definition of `fac/1`

we see two definitions; one for $n=0$ and another for all values of $n\gt0$.