Your friends at Viget present Extend, a Code & Technology Blog

OTP: a Functional Approach (or Three)

I intially started the OTP challenge as a fun way to write some OCaml. It was, so much so that I wrote solutions in two other functional languages, Haskell and Elixir. I structured all three sets of programs the same so that I could easily see their similarities and differences. Check out the encrypt program in all three languages and then I’ll share some of my favorite parts. Go ahead, I’ll wait.

OTP: Matlab Solution

Matlab isn't the most popular programming language out there (especially given that an individual license will run you over $2,000**), but it's incredibly powerful. For me, it also has a nostalgic appeal, as analyzing fMRI data with Matlab scripts served as my introduction to programming. So when David posed his One Time Pad programming challenge I relished the opportunity to relive some of the magic and mystery of Matlab.

OTP: a Language-Agnostic Programming Challenge

We spend our days writing Ruby and JavaScript (and love it), but we’re always looking for what’s next or just what’s nerdy and interesting. We have folks exploring Rust, Go, D and Elixir, to name a few. I’m personally interested in strongly-typed functional languages like Haskell and OCaml, but I’ve had little success getting through their corresponding animal books. I decided that if I was going to get serious about learning this stuff, I needed a real problem to solve.

Inspired by an online course on Cryptography, I specced out a simple one-time pad encryptor/decryptor, pushed it up to GitHub and issued a challenge to the whole Viget dev team: write a pair of programs in your language of choice to encrypt and decrypt a message from the command line.

Rubyists: Just use double-quoted strings.


If you've written Ruby, you've heard it before: Use single quoted strings unless you need string interpolation.

It makes sense, right? When I instantiate strings using double quotes, the Ruby intepreter has to do extra work to figure out if it needs to perform interpolation. Since extra work means reduced performance, it seems reasonable to avoid double-quoted instantiation unless it's a necessity.