Code Fugue

Music Update

2020-09-17T00:00:00+00:00

Hey, I’m trying to step away from social media, which has reminded me that I have this blog. My musical life has picked up a bit in the last couple of years, and I thought I would throw out an update here just for fun.

Photo by Paul Martin

In early 2018 I started playing keyboards in a Beatles cover band called The English Rain. Sorry to brag, but these guys are really good, and I work hard to keep up with them. No, we don’t dress up in wigs and suits; we just try to recreate the original sound as faithfully as possible. This means Epiphones, Gretsches, Rickenbackers, a Hofner bass, and lots of attention to vocal harmonies. We usually have a regular monthly outdoor gig in downtown Franklin through the summer, but this year, for obvious reasons, we did not.

To keep ourselves entertained during the lockdown, we made a few quarantine home performance videos of some of our favorite 70s and 80s tunes. We used the name “The Shut-Inz” so people wouldn’t think The English Rain had given up on The Beatles. Yes, I am trying to avoid social media, but if you’re still playing that game you can see these videos on our Facebook page and/or our YouTube channel. The sound is better on YouTube, but on Facebook there are also some live stream replays if you’re into that kind of thing.

Since this is offically a software blog, I’ll mention that I have done a good bit of coding for my laptop-based keyboard rig. Sometimes I don’t have quite enough hands to cover all the parts and have to use a little magic. This is how I have approached “Martha My Dear” and “The Long and Winding Road,” and I’m still trying to figure out how to make “Honey Pie” happen. Maybe I’ll write more about that later.

I have also been playing keyboards with a theme-driven band called The Decades. They are a talented bunch of twenty-somethings with an inexplicable knowledge of and affection for the music of my generation. This is the least efficient band possible; so far each gig has had a completely different set list, hardly ever recycling anything. It’s a lot of work, but it never gets boring. Thus far we have done:

70s and 80s Classic Rock
90s Radio Pop
Christmas Tunes
Country Originals
Disco!
Movie Songs

These band endeavors have also led to the opportunity for me to do a little session work, which I have not done in many, many years. I am very fortunate at my age to be still learning and growing in the things that I love. It was the hope of doing these kinds of things that drew me to Nashville in the first place. I’m still happy to be here.

Whatever it is that you love to do outside of work, I hope you’re finding or making opportunities to do it. Have fun out there, and please stay safe!

OH: Confessions of a Tweet Thief

2017-10-15T01:33:11+00:00

Most of my developer friends who have achieved any amount of public recognition or notoriety have reported experiencing some measure of impostor syndrome. They feel that they have garnered a reputation that surpasses their actual level of competence and contribution. It always brings me great comfort to hear this, because I feel the same way. Or am I just pretending so that I’ll feel more like one of them? 😉

Well, I recently went beyond the syndrome and proved myself an actual impostor, a fraud, a phony. A plagiarist, to be specific. One evening last month I was sitting at home doing something useless on my laptop when my eldest spawn told me a geeky math joke. I thought it was very clever. I thought my geeky friends would appreciate it as well. So I tweeted it.

This Fibonacci joke is as bad as the last two you heard combined.
— Calvin Bottoms (@calvinb) September 13, 2017

The next morning I awoke to a deluge of notifications of responses, likes, and retweets beyond anything I’ve ever experienced on Twitter. This tweet had taken flight for some reason. I got replies from some of my geek heroes who neither know me nor follow me.

I have a feeling the next one will be at least as bad again.
— Dan North (@tastapod) September 13, 2017

I was at work when I saw the notification that I had been retweeted by Australian comedian Tim Minchin.

Oh yes. https://t.co/pS1YPyKcBj
— Tim Minchin (@timminchin) September 13, 2017

What was happening? I guess it was my twenty minutes of Twitter fame. I started looking through the responses. One that caught my eye (and my stomach) was addressed to @sigfpe and said simply,

Congrats on getting your tweet stolen https://t.co/3D2WriOhAK
— Kevin Lin (@quasicoherence) September 14, 2017

Oh, no. I had stolen this man’s tweet. In retrospect I suppose I could have googled the joke so I could attribute it properly, but I wasn’t writing a research paper, and I had no idea anyone other than my geeky friends would even see it. I composed a quick explanation/apology tweet to @sigfpe, confessing that I owed him a large number of retweets. It was one those times that 140 characters did not feel like enough, but he could not have been more gracious about it, and I am very grateful.

If your kid told you it that makes my day 😁
— Dan Piponi (@sigfpe) September 14, 2017

Such social media points mean nothing to some people but an awful lot to others, and I had just collected someone else’s jackpot. So @sigfpe, thank you for being so cool about this whole thing and seeing it for the inadvertent act that it was. I really liked your joke, and I clearly am not alone.

Man, Twitter is kind of frightening. It’s fortunate that important people don’t use it to talk about real things.

Nodevember 2016

2016-11-17T04:05:00+00:00

I just got done with Nodevember 2016, where I saw some great talks, caught up with some old friends, and made some new ones. I also had a fun time hanging out in person with some of my LeanKit co-workers who work remotely, and I work with the greatest people in the world, so that’s always wonderful. I had the privilege of presenting a new talk I called “Arts and Sciences: Programming Music on the Web.” I had a fabulous crowd who were so onboard and engaged, and they made it so much fun! If you were there, thank you for making it such a blast!

The slides for my talk are available here, and you can find the “Beep Boop” BASIC code I showed at https://github.com/calvinb/beep-boop.

In case you’re interested in the recordings of the early computer music demos I mentioned, here are the links:

Go build something fun!

F-Words Slides

2014-09-26T22:02:00+00:00

Thanks to everyone who came to my "F-Words" talk on functional programming terms at CoderFaire Tennessee. Here are the slides.

https://docs.google.com/presentation/d/1CP8I2rr4ZuQ1l7iJz7MTbJXTXdFoVHug7QRw7Mdzpgc/edit?usp=sharing

Partial Application vs. Currying

2014-06-28T08:06:00+00:00

Is the entire world of aspiring functional programmers generally confused about partial function application and currying, or is it just me? I like to feel well-informed when I think to myself that these two are not the same thing, but I still couldn’t tell you what the difference is. To me they are like Bill and Ted on their Excellent Adventure; I know them when I see them, but I don’t know which is which. I have just decided it is time to dive in and get this straight. So here we go.

Divide and Conquer

Partial function application and currying both have to do with decomposing multi-parameter functions into smaller functions with fewer parameters. For example, in Haskell we might have an add function that takes two integers and returns their sum:

add :: Integer -> Integer -> Integer
add x y = x + y

If I had this function available and wanted another function that took one number and added 3 to it, I could do this:

add3 :: Integer -> Integer
add3 = add 3

Now this function does just what we want.

add3 2    --> 5

When I see this kind of thing, I can say with confidence, “Ah, that’s that currying/partial application deal.” But which is it? Either one? Both?

After spending a little time digging in, I think my main problem here is that I’m only concerned about these concepts when working in languages whose functions support it implicitly, in my case Haskell and F#. I get these two bits of functional magic free in a gift bag, but since they’re always wrapped up together, they feel like one thing instead of two.

Break It Down

Of the two concepts, partial application is the easier to understand, thanks to its meaningful name. It is just what it sounds like. You have a function that takes more than one parameter, you pass it fewer parameters than it wants, and it returns a new function that will take the remaining parameters and return you your result, as we just demonstrated with our add3 function. It is partially applied, applied to some of its parameters with the option to apply the resulting function to the rest later.

So what is currying? Currying is the transformation of one multi-parameter function into a chain of single-parameter functions that ultimately yield the same result. The problem with trying to discuss currying in Haskell and F# is that they don’t have multi-parameter functions in first place. A function such as add, which logically has multiple parameters, is defined implicitly as a chain of single-parameter functions, or in the curried style. So when does the currying take place? I would have to say at compile time. No wonder I was missing it!

In Haskell and F#, currying is more their style of implementing multi-parameter functions than it is a technique that we use when writing in these languages. The functions are curried, period, whether or not we choose to partially apply them, which is the only time we would think to notice.

Build It

To get a feel for what is involved here, we need to get away from this implicit currying and go somewhere we have support for true multi-parameter functions, and we can build this stuff ourselves. JavaScript, anyone? JavaScript, like most imperative languages, and unlike Haskell and F#, supports true (non-curried) multi-parameter functions. (Its bind function provides partial application support as well, but we still want to build our own so we can see what’s happening.) Let’s start with our add function again.

var add = function (x, y) { return x + y; };

Now we can build a function to partially apply another two-parameter function by taking it and its first parameter, and returning a new function that takes the second parameter and returns the result.

var papply = function (fn2, x) {
    return function (y) { return fn2 (x, y); };
};

Now we can use this function to build our add3 function by partially applying add.

var add3 = papply(add, 3);
var five = add3(2);  //--> 5

Notice how that was more work than partially applying in Haskell? That’s because a curried function gives you partial application pretty much free; the single-parameter component functions are already in there, just waiting to be let out. Let’s build a curry function in JavaScript to demonstrate this. Remember currying is the transformation of a multi-parameter function into a chain of single-parameter functions, so our curry function will take a function and return a function. Let’s assume our input function takes two parameters, like our add.

var curry = function (fn2) {
    return function (x) {
        return function (y) {
            return fn2(x, y);
        };
    };
};

We can use this function to create a curried version of add.

var cAdd = curry(add);

This function will return the same results as add but has to be called differently, since it is a chain of single-parameter functions.

var five = cAdd(3)(2);  //--> 5

Now back to the idea of how the curried style gives us partial application free of charge. Look at how we can partially apply our cAdd:

var add4 = cAdd(4);
var seven = add4(3);  //--> 7

Do you see what we’ve got here? Currying is a way of defining a function; partial application is a way of applying a function. Currying is about construction; partial application is about consumption, with a by-product. Some functions are curried, but no functions are partial.

Undo

In the words of Blood, Sweat, and Tears, what goes up must come down, and curried functions can be uncurried (in languages that support multi-parameter functions). Uncurrying would be the transformation of a chain of single-parameter functions into one multi-parameter function. Here is a function that will do that for us:

var uncurry = function (cfn2) {
    return function (x, y) {
        return cfn2(x)(y);
    };
};

Now we could use this function to create a new add function from our curried cAdd.

var newAdd = uncurry (cAdd);
var eight = newAdd(5, 3);  //--> 8

Excellent! We have separated partial application from currying. I think I might be able to remember the difference now. I hope you will, too.

Magic Not in the Monad

2014-05-13T07:46:00+00:00

I am recently coming to grips with a foundational misconception I have been entertaining about monads, possibly since I first heard the term. I am not a category theorist, and I first encountered monads in the context of functional programming. For me the monad has always been shrouded in mystery and sporting a reputation of being very difficult to understand.

My misconception is that I have associated monads with side effects. Before I started learning Haskell, I heard someone say, “If you need to produce a side effect in Haskell, you have to use a monad.” This is not untrue, but the way it is stated is misleading. It would be more accurate to be more specific and say you have to use the IO type constructor. But IO is a monad, so where’s the harm?

It didn’t help me that IO is so often referred to as “the IO monad.” IO’s imperative side effect business makes it a unique thing in the Haskell world. I attributed at least some of that uniqueness to its monad-ness, but the two have nothing to do with one another. Other monads do not have side effects, and IO can wield its side effects without being treated like a monad.

The epiphany of my error occurred during a recent NashFP discussion in which I found myself surprised to see that Maybe was a monad. The Maybe type class, being perhaps the simplest example of a context, is a great case to consider since there is minimal magic to get distracted by. How could Maybe be a monad when monads are magic and Maybe is not? I had to take a look and see what other non-magical monads were hanging around.

We can use the :info command to ask ghci (Glasgow Haskell Compiler Interactive) what Monad instances it has loaded right out of the box.

Prelude> :info Monad
class Monad m where
  (>>=) :: m a -> (a -> m b) -> m b
  (>>) :: m a -> m b -> m b
  return :: a -> m a
  fail :: String -> m a
    -- Defined in `GHC.Base'
instance Monad Maybe -- Defined in `Data.Maybe'
instance Monad (Either e) -- Defined in `Data.Either'
instance Monad [] -- Defined in `GHC.Base'
instance Monad IO -- Defined in `GHC.Base'
instance Monad ((->) r) -- Defined in `GHC.Base'

Here we see first the four functions of the Monad type class, and then the instances, which are what we’re after. There are five Monad instances in GHC.Base, and they are Maybe, Either, list, IO, and function. Yeah, the syntax is weird, but ((->) r) is the function function. Functions are monads. Go chew on that one awhile. Every one of these Monad instances except IO is utterly commonplace and non-magical.

So there is monad without magic. How about magic without monad? What do we know about IO other than that it’s a Monad instance? Let’s ask ghci.

Prelude> :info IO
newtype IO a
  = GHC.Types.IO (GHC.Prim.State# GHC.Prim.RealWorld
                  -> (# GHC.Prim.State# GHC.Prim.RealWorld, a #))
    -- Defined in `GHC.Types'
instance Monad IO -- Defined in `GHC.Base'
instance Functor IO -- Defined in `GHC.Base'

Of course! It’s a Functor, as Monads almost always are. Let’s talk to it like a plain old Functor. How do we talk Functor? Back to ghci.

Prelude> :info Functor
class Functor f where
  fmap :: (a -> b) -> f a -> f b
  (GHC.Base.<$) :: a -> f b -> f a
    -- Defined in `GHC.Base'
instance Functor Maybe -- Defined in `Data.Maybe'
instance Functor (Either a) -- Defined in `Data.Either'
instance Functor [] -- Defined in `GHC.Base'
instance Functor IO -- Defined in `GHC.Base'
instance Functor ((->) r) -- Defined in `GHC.Base'
instance Functor ((,) a) -- Defined in `GHC.Base'

Ah, yes, fmap is the only function in the Functor type class. If IO is just a Functor, we should be able to fmap over it. What is the simplest way to get an IO value? My favorite is the getLine function, which will give us an IO String.

Prelude> :type getLine
getLine :: IO String

To fmap over an IO String, we need a function that takes a String and returns a simple value. Let’s use (++"!"), which will “shout” any string we apply it to. A simple use would look like this:

Prelude> (++"!") "Hi"
"Hi!"

Now let’s try to fmap that function over an IO String, which we will get from getLine.

Prelude> fmap (++"!") getLine
Hello
"Hello!"

Look at that. We just used IO as a Functor (via fmap) without using any Monad functions or features. It still waited for input. It still got an unpredictable value. It still did its magic thing as a plain old Functor.

So there we have it. The magic is in IO alone, not in Monad. I’ll try to write more soon about what the monad mojo is, now that we have spent some time on what it is not.

Rebuilding Haskell in C#: Functors

2014-01-20T21:23:00+00:00

Look out; I’ve been digging into Haskell again. I enjoy learning about Haskell, but more than that, I enjoy learning to think in a functional way. Haskell is a particularly good language to facilitate that, as it is arguably the most functional of functional languages. It boasts “pure” functionality, and while some might believe that means it is of no practical use, I think it makes it pretty cool.

While I enjoy my Haskell studies, I still struggle with a few core concepts. For example, I keep having to go back and reread explanations of Functors. I understand them at the time, but it doesn’t stick, and I keep having to come back and read it again. Maybe my appreciation for some of the staples of Haskell would be a little less volatile if I had the experience of implementing them myself in an imperative language like C#.

To implement Functors, there are a few building blocks we’ll need first, and it will be helpful to establish a simple concept map between pieces of Haskell and C#. Let’s start with one of the foundational constructs of the functional world, the map function. The type of Haskell’s map function is defined like this:

map :: (a -> b) -> [a] -> [b]

This means that the map function takes a function that takes a value of type a and returns a value of type b, and a list of values of type a, and returns a list of values of type b. In fewer words, it takes a function from a to b, and a list of a, and returns a list of b. It takes a function and a list of inputs to it, and returns a list of outputs. You’ve probably seen this kind of thing in other languages. I think I first encountered it in Ruby. Shortly thereafter I was thrilled to see that LINQ had brought this goodness to .NET in the form of the Select extension method on IEnumerable. Of course the LINQ implementation uses the very OO approach of adding an extension method onto the IEnumerable type. Its signature looks like this:

public static IEnumerable<TResult> Select<TSource, TResult>(
    this IEnumerable<TSource> source,
    Func<TSource, TResult> selector
)

Stare at the two for a minute if you need to; the Haskell type and the C# method signature say exactly the same thing, only stated in reverse order from one another. (And C# takes a heck of a lot more notes to name that tune.)

So the two languages have some common ground to start with. Now we need to get a little bit of Haskell vocabulary under our belts. I will try to describe Haskell constructs in terms of C# constructs as much as possible.

Type Classes

Try to ignore the word class; it’s not like an OO class. A type class in Haskell is closer to an interface in OO. Types can be instances of various type classes much like classes in C# can implement various interfaces. A type class comprises a list of functions, and any type that wants to be an instance of that type class must implement its functions. It might not be too much of a stretch to say it is interface implementation. Each instance type has its own unique implementation of each function, just as each implementing class has its own unique implementation of an interface’s members, affording the system the same benefits of polymorphism that we have always enjoyed in OO.

Type Constructors

You can think of a type constructor as something like a generic type in .NET, such as List<T> or Nullable<T>. It can’t stand alone as a type; it needs another type to make it complete. You can’t instantiate a List<T> unless the identifier T is bound to an actual type such as int or string. Type constructors work the same way.

Functors

Haskell’s Functor is a particular type class, and it’s pretty simple as type classes go, in that it has only one function, fmap, but it wields some serious power. fmap’s type is defined like this:

fmap :: Functor f => (a -> b) -> f a -> f b

This means that, given that a type constructor f is a functor, fmap takes a function that takes an a and returns a b, and an f of a, and returns an f of b. We could express this signature in C# like this:

IFunctor<TResult> FMap<TSource, TResult>(
    Func<TSource, TResult> func,
    IFunctor<TSource> input
)

It is commonly stated that functors are structures than can be “mapped over.” They establish a context that contains a particular type of value, and then they can take a function, apply it to the contained value, and wrap up the result in the same type of context again, returning the new context as the result. Think of the map function we just looked at. It maps functions over lists. It pulls a value out of a list, applies a function to it, and puts the result into a list. Hey, if lists can be mapped over, does this mean that lists are functors? Why, yes, it does. Take another look at the fmap type definition above and think of f as a context. f a represents an a in this context. f b represents a b in the same type of context. Now imagine that context is a list, and therefore that f a is a list of a. As it turns out, map is the list’s implementation of fmap that makes it a Functor instance. Nice!

A C# Implementation

But can we do this in C#? The Select method uses generic type variables to give its parameters the same flexibility that Haskell’s map function has. It uses IEnumerable as its context in place of Haskell’s list. Now we’re looking to define a new generic type that could take the place of IEnumerable. If different functor types have different implementations of fmap, we’re headed for some polymorphism here. If we’re going to implement fmap polymorphically in C# we’ll need an interface and at least one class. Since we’re going OO here, we’ll eliminate the input parameter we included before and replace it with a self reference (this) in the implementation.

First the interface:

interface IFunctor<TSource> {
    IFunctor<TResult> FMap<TResult>(Func<TSource, TResult> func);
}

Simple enough. Now for a class to implement it. Let’s try a list. It will implement IEnumerable for its list-ness, and IFunctor for its functor-ness.

class MyEnumerable<TSource> :
    IEnumerable<TSource>, IFunctor<TSource>

Now for a bare-bones, boilerplate implementation of IEnumerable, we'll just take an IEnumerable in the constructor and delegate any IEnumerable concerns to it.

    private readonly IEnumerable<TSource> _collection;

    public MyEnumerable(IEnumerable<TSource> collection) {
        _collection = collection;
    }

    public IEnumerator<TSource> GetEnumerator() {
        return _collection.GetEnumerator();
    }

    IEnumerator IEnumerable.GetEnumerator() {
        return GetEnumerator();
    }

Thanks to System.Linq and the Select extension, MyEnumerable already has the ability to map functions over itself, but it can’t join in any functor games until it implements IFunctor’s FMap. Fortunately, we can have FMap delegate to Select, since it already does the same thing. Select takes the value from the context (MyEnumerable) and applies the function, but it’s still up to us to put the result back into context, which we can easily do by passing it to MyEnumerable’s constructor.

    public MyEnumerable<TResult> FMap<TResult>(
        Func<TSource, TResult> func
    ) {
        return new MyEnumerable<TResult>(this.Select(func));
    }

There’s the MyEnumerable-specific implementation. Now let’s just add the explicit interface implementation and have it delegate to the method we just added.

    IFunctor<TResult> IFunctor<TSource>.FMap<TResult>(
        Func<TSource, TResult> func
    ) {
        return FMap<TResult>(func);
    }

That’s it. We have implemented a functor in C#. Let’s try it out before we move on. Say we have a function that takes an integer and returns a string of its square.

string SquareString(int i) {
    return (i * i).ToString();
}

And we have a list of integers that we want to map this function over.

MyEnumerable<int> list = new MyEnumerable(new[] {1, 2, 3, 4});
MyEnumerable<string> squareStrings = list.FMap(SquareString);
//=> {"1", "4", "9", "16"}

Of course, in C# we tend to love lambdas, and we could just as easily do it that way.

squareStrings = list.FMap(i => (i * i).ToString());
//=> {"1", "4", "9", "16"}

But wait a minute. We haven’t done anything but wrap Select, have we? So far, yes, but think about this: What if the context we want to map over is not a listy kind of thing? Another functor type in Haskell is Maybe a, which is just like .NET’s Nullable<T>. It has a particular type, and it may or may not have a value. Just like a list, it provides a context for particular type of value, only in this case the context is the possibility of there being no value. Let’s throw together our own homegrown nullable class.

class MyNullable<TSource> : IFunctor<TSource>

The guts are pretty simple.

    private readonly bool _hasValue;
    private readonly TSource _value;

    public MyNullable() {}

    public MyNullable(TSource value) {
        _hasValue = true;
        _value = value;
    }

    public bool HasValue {
        get { return _hasValue; }
    }

    public TSource Value {
        get { 
            if (_hasValue) return _value;
            throw new InvalidOperationException(
                "Nullable object must have a value.");
        }
    }

Now for the FMap implementation. Once again, we take the value from the context, apply the function, and wrap it up in context. In this case, if the MyNullable<TSource> instance has a value, we apply the function and put the result into a new MyNullable<TResult>. If there is no value, we simply return a new empty MyNullable<TResult>.

    public MyNullable<TResult> FMap<TResult>(
        Func<TSource, TResult> func
    ) {
        return HasValue 
            ? new MyNullable<TResult>(func(Value)) 
            : new MyNullable<TResult>();
    }

    IFunctor<TResult> IFunctor<TSource>.FMap<TResult>(
        Func<TSource, TResult> func
    ) {
        return FMap(func);
    }

Now let’s see what MyNullable can do.

var nullInt = new MyNullable<int>();
// nullInt.HasValue == false

var three = new MyNullable<int>(3);
// three.HasValue == true
// three.Value == 3

var ss3 = three.FMap<string>(SquareString);
// ss3.HasValue == true
// ss3.Value == "9"

var ssNull = nullInt.FMap<string>(SquareString);
// ssNull.HasValue = false

Conclusion

Okay, so we have implemented Haskell’s Functor in C#. What is the value in this? Remember the goal of this exercise was not to bring C# something that I thought it needed, but rather to help me understand what Functors are doing for us in Haskell. What I find here is that it’s all about separation of concerns. The benefit of the separation is in the reusability of the functions that we pass to fmap.

Each Functor, or type context, has its own set of concerns that are not the business of any function we might want to map over it. The list and MyEnumerable need to iterate, call the specified function multiple times, and collect the results into a new list. The Maybe and MyNullable need to deal with the absence of a value and possibly not call the specified function at all. This Functor mechanism enables simple functions such as SquareString to be reused in these and limitless other contexts that they are unaware of. Each Functor context can take any simple function, and each simple function can be used in any Functor context. Without the Functor, we would have to code each function-context combination separately. With it, we have a pallette of primary colors that can be combined in unforeseen and beautiful ways.

Polyglot Survival Guide: Erlang, Haskell, F#, and Elixir

2014-01-20T15:43:00+00:00

Lately I have been bouncing back and forth between Erlang and Haskell, two profoundly significant functional languages that I find both very different and very similar. They are very different in their philosophies and thought patterns, particularly around data types, but both being non-LISPy functional languages, they have enough similarities that I sometimes having trouble keeping them straight when I am coding. So I have started a simple list here cataloging some of their differences side by side. I imagine I will continue to add to it over time. Please comment to let me know what other features or constructs you might like to see added here.

I have now added entries for F# and Elixir, which I am also working with lately. While Elixir is the least adopted so far, I put it right after Erlang, since their relationship leads to a lot of similarities in the details cataloged here.

Functional Purity

Erlang: no
Elixir: no
Haskell: yes (in that all side effects are relegated to the IO monad)
F#: no

REPL

Erlang

erl

Elixir

iex

Haskell

ghci

F#

fsi

Exiting the REPL

Erlang

q().

Elixir

ctrl-c ctrl-c

ctrl-g q

Haskell

:q

F#

#quit;;

Line terminators

Erlang: English-like (, ; .)
Elixir: none
Haskell: none
F#: none

Typing

Erlang: dynamic
Elixir: dynamic
Haskell: static with inference
F#: static with inference

I/O

Erlang: io, file, and some other modules
Elixir: IO, File, and some other modules
Haskell: IO monad
F#: .NET Framework

Printing

Erlang

io:format("Hello~n").

Elixir

IO.puts "Hello\n"

Haskell

putStrLn "Hello"

F#

printfn "Hello"

Variable names

Erlang

PascalCase

Elixir

snake_case

Haskell

camelCase

F#

camelCase

Atoms

Erlang

atom

Elixir

:atom

Haskell

(none)

F#

(none)

Laziness

Erlang: hackable with funs
Elixir: streams lazy, lists not
Haskell: by default
F#: sequences lazy, lists not; explicit with lazy keyword

Infinite lists

Erlang: hackable with funs
Elixir: streams, yes; lists, no
Haskell: absolutely
F#: sequences with yield

Currying

Erlang: explicit with lambdas, no dedicated syntax
Elixir: explicit with lambdas, no dedicated syntax
Haskell: implicit
F#: implicit

Side effects

Erlang: yes
Elixir: yes
Haskell: never, except via the IO monad
F#: yes

Tuples

Erlang

{"foo", "bar"}

Elixir

{"foo", "bar"}

Haskell

("foo", "bar")

F#

"foo", "bar"

List construction/matching

Erlang

[Head|Tail]

Elixir

[h|t]

Haskell

x:xs

F#

x :: xs

Heterogeneous lists

Erlang: yes
Elixir: yes
Haskell: no
F#: no

Function calls

Erlang

add(1,2)

Elixir

add(1,2)

add 1,2

Haskell

add 1 2

F#

add 1 2

Lambdas

Erlang

fun(X,Y) -> X + Y end

Elixir

fn x,y -> x + y end

&(&1 + &2)

Haskell

\x y -> x + y

F#

fun x y -> x + y

List comprehensions

Erlang

[X || X <- [1,2,3,4,5], X > 3]

Elixir

for x <- [1,2,3,4,5], x > 3, do: x

Haskell

[x | x <- [1,2,3,4,5], x > 3]

F#

{ for x in 1 .. 5 when x > 3 -> x }

Converting integer to string

Erlang

integer_to_list(123)

Elixir

to_string 123

Haskell

show 123

F#

string 123

Comments

Erlang

% comment after percent

Elixir

# comment after pound sign

Haskell

-- comment after double hyphen

F#

// comment after double slash

Mapping

Erlang

lists:map(fun(X) -> X*X end, [1,2,3]).

Elixir

Enum.map [1,2,3], &(&1 * &1)

Haskell

map (x -> x*x) [1..3]

F#

List.map (fun x -> x*x) [1 .. 3]

Elixir: Language Love Child?

2013-04-28T21:04:00+00:00

Different programming languages, like different people, have their strengths and weaknesses. Some are simple; some are complex. Some are friendly to the programmer; some are friendly to the processor. Some cater to brilliant minds; some cater to other minds. I have spent a significant portion of my development career writing code in C#, which is accurately described as a general purpose language. It aims to be able to do most anything, rather than to be the best at any one particular thing.

After several years of living mostly in C#, I ran across Ruby and fell in love with it. It’s no surprise, because Ruby was designed to optimize for developer enjoyment. It’s very readable with low ceremony, and it takes no time to get something up and running. The down side is that it is not fast in execution. It’s one of the slowest languages in use today, but when I’m writing Ruby, I don’t care. I write in Ruby when speed of development is more important than speed of execution, or when I just want to have fun.

Lately I’ve been dabbling in Erlang, which I would put at the other end of the spectrum from Ruby. Erlang is a generation-old functional language that is all about concurrency and fault tolerance. Its runtime, called OTP (Open Telecom Platform), does a shockingly good job of solving a lot of the concurrency and uptime problems facing the software world in recent years. The Erlang language is clearly tailored to the needs of a concurrent runtime, and it achieves this goal brilliantly. One down side is the syntax. Erlang’s syntax is unusual, and it is not often described as pretty. Even among real lovers of Erlang, I haven’t heard anyone defend its syntax. We just accept the syntax because we’re more concerned with concurrency and reliability.

But is it ever possible to have our cake and eat it, too? What if we were so demanding as to ask for the beauty of Ruby’s syntax and the concurrency magic of Erlang on the same platform? Enter Elixir. Worlds are colliding. Elixir is a language that runs on the Erlang runtime but sports a syntax that looks an awful lot like Ruby. The best of both worlds? Could be. I’m just now gearing up to dig in and see. Elixir, I’m rooting for you.

Moops! Haskell, IO, and the Bubble Boy

2012-05-28T13:53:00+00:00

I recently set out to get Haskell connected to a PostgreSQL database. The task ended up having almost nothing to do with PostgreSQL and everything to do with Haskell’s militant stance on functional purity. I chose to use HDBC since it appeared to be the most vanilla approach. Before I even got to the point of trying to open a database connection, I was confronted with a philosophical conundrum not too different from the sound of one hand clapping.

I’ll provide some code here in case you want to follow along in ghci (the Glasgow Haskell Compiler Interactive), but I’m really more about the philosophy here. First I imported the HDBC library and the PostgreSQL driver.

ghci> import Database.HDBC
ghci> import Database.HDBC.PostgreSQL

Next, I see that the library has a function called connectPostgreSQL whose job is to open a connection for me. I have always admired Haskell’s commitment to functional purity, even though I have wondered sometimes whether that rendered it useless in real life. Haskell functions operate under the same constraints as mathematical functions. According to Wikipedia, in mathematics, a function is, “a relation between a set of inputs and a set of potential outputs with the property that each input is related to exactly one output.” A function, given a particular input, will always return the same result. Pure functional programming adds the constraint that a function will have no side effects.

I have connected several programming languages to databases, and they have mostly worked in the same general way. You call a function or method with some basic connection information, it opens a connection, and you get back an object reference or a handle that can subsequently be used to interact with the connection that has been opened. How will this work in a pure functional language? Opening a database connection is a side effect in the first place, so we’re already breaking the rules, and we haven’t even done anything yet.

Let’s ignore that for the moment and think about what the function’s result should be. What type of value is this function going to give me? Once I have my connection details defined and pass them to this function, it should return me a handle to an open database connection, right? Well, it will if the connection information is correct, and the server is running, and I have a network connection to it, and my password hasn’t expired, etc. This exact function call might give me a connection one time, but then I can turn off my wireless and call the function again, and I will get a very different result. Mathematics would tell me this is not a function. Haskell would agree.

This whole operation of opening a database connection is tainted. It is not a mathematical operation. It is not a functional operation. It is imperative by nature. It is entirely side-effect driven. It is not about getting an answer; it is about changing something in the world. Haskell does not take this lightly. It does not prevent you from doing it, but it does not allow such tainted operations to pollute its pristine functions. Such imperative, side-effect-riddled operations are relegated to a language feature known as the IO action. (The IO action is technically a monad, but that’s a topic for another day.) The connectPostgreSQL function by definition cannot return me a handle to a connection that it may or may not be able to establish, but it can reliably return me an IO action that by definition behaves imperatively and unpredictably. This IO action is our window into the cruel outside world. It is our bubble.

Haskell is the bubble boy. In his world there are no germs, no file systems, no databases, no spotty networks, only pure math. The IO action is his window to the outside world, his bubble. He can see through it, talk through it, and use those hose sleeves and rubber gloves to play Trivial Pursuit through it, but he can never actually touch anything. If did, he would be contaminated, infected, tainted, impure. The bubble keeps him safely insulated from all the brutal unpredictability of the outside world.

So the connectPostgreSQL function can’t return me a database connection, but it can predictably and consistently return me an IO action, which is by definition tainted, impure, unpredictable, and unreliable, and this IO action just might, in the perfect alignment of the stars and all favorable circumstances, contain a database connection for me. We can ask ghci for the type of the function like this:

ghci> :type connectPostgreSQL
connectPostgreSQL :: String -> IO Connection

Here we see that it takes a String (providing connection details) and returns an IO action that might give us a Connection. Once again, this function will always succeed. The perils of the impurity of the outside world pose us no threat until we ask the IO action for the connection. We can do this with the <- operator.

ghci> let io = connectPostgreSQL "dbname=mydb password=secret"
ghci> :type io
io :: IO Connection
ghci> -- Here's the scary part:
ghci> conn <- io
ghci> -- Hey, it worked!
ghci> :type conn
conn :: Connection

If we have made it this far, we now have a connection handle that we can use to execute queries. There’s a function here called quickQuery for doing just that. Of course, the connection could be severed at any time by forces entirely beyond our control. Even if the connection could be reliable, the same select query may very well yield a different result every time I execute it. That’s kind of the point of having a database, right? I think you know what I’m gettting at here. If the operation’s result is unpredictable, it can’t be a function.

Once again, IO action to the rescue. quickQuery can still be a function if it predictably returns an IO action instead of a surprise from some flaky database.

ghci> :type quickQuery
quickQuery
  :: IConnection conn =>
     conn -> String -> [SqlValue] -> IO [[SqlValue]]

This tells us that quickQuery takes a conn (which must be some type of IConnection), a string (for the query), and a list of SqlValues (for proper query parameters to avoid SQL injection attacks), and it returns us an IO action. This IO action, however, may contain in its tainted wildness not a database connection but a list of lists of SqlValues. Of course the outer list can be seen as list of rows, and the inner lists as lists of column values.

ghci> let resultIO = quickQuery conn "select count(*) from some_table" []
ghci> :type resultIO
resultIO :: IO [[SqlValue]]
ghci> --That was safe: now the scary part:
ghci> result <- resultIO
ghci> --Whew, got lucky again.
ghci> :type result
result :: [[SqlValue]]
ghci> result
[[SqlInteger 4]]

At this moment we can see that some_table has 4 rows in it. When I make that exact function call again, it might have 5, but it doesn’t compromise the purity of the function because that number is not the function’s result. That number is the result of executing an IO action, which does not pretend to have the determinism of a function. The pure function has the IO action do its dirty work.

Life is unpredictable, but mathematics is not. The IO action gives Haskell the means to exploit the predictability of its mathematical bias but still interact with the unpredictable outside world, thereby making it, well, useful.