Understanding whether or not I should make struct fields public was one of the hardest challenges in learning Rust. With OO languages such as Java and C# the rule is incredibly easy: always make fields private and use getters and setters for access. And when starting with Rust, my immediate impulse was to follow this same rule, but it quickly becomes clear that that simple rule is not right for Rust.

The experience of learning a new language. Around the beginning of the year, I began to teach myself the Rust programming language. While learning Rust, one sensation that I felt to an incredible degree was the sense of being “dumb”. As I wrote code in Rust, the code quality felt poor, my designs felt clumsy, and I felt like I’d lost all my abilities to write code. What bothered me was why?

As a follow up to my post about Zippers for lists and binary trees, I wanted to create a zipper for a slightly more complex data structure. The Rose Tree is a tree structure where the number of branches a node may have is variable. An example of a rose tree would be the directory structure on your computer: each directory may contain 0 or more sub directories which, in turn, may contain addition subdirectories.

One of the coolest things about working with F# (and other ML languages) is the incredibly elegant way that mathematics intersects with programming, to inform powerful tools for our toolbox. Algebraic Data Types (ADTs) are the source of a large amount of this mathematical invention. Recently, I’ve been exploring the algebra and calculus of types and what happens when you take the derivative of a type. Zippers are a type pattern which provide a functional way to interact with and transform data structures: linked lists, binary trees, rose trees, etc.

Given $$B$$, a band, and $$S$$, the set of all songs composed by $$B$$ then $$B$$ is Prog iff $$\exists s \in S$$ such that $$s$$ contains the sound of a baby. Testing out MathJax and Jekyll.

While visiting San Diego, for some much needed time off from work, I had a fantastic evening hanging out my friend Steve Bjorg and his family. As the bookend to the evening, Steve and I sat down and had chatted about reading books. It started as merely a random topic on which to build an enjoyable conversation, but quickly morphed into a discussion about how to represent knowledge. The driver behind our discussion was an exploration of my inability to read technical books on a Kindle or computer.

It has been quite a long time since my last blog post. Quite a lot has happened in that time. I moved from San Diego to Chicago. I got a new job and now the CTO for a small start up company out in Chicago. I have switched off of Windows development to Linux development. I have gone though doing my work on a Windows box, to a Linux box, and now I’m on a MacBook.

In Part 3 of this Tutorial, I talked a little about erased types and how the types we generate are actually built on top of a obj. Previously, I just used a plan obj type and cast an integer to and from the obj types. InvokeCode= (fun args -> <@@ 0 :> obj @@>)) Using just the basic obj works well enough for a very simple generated type (like the simple integer from part 3).

In the last tutorial, we built a simple type named Hello which had some static members. In this tutorial, we’ll expand our Hello type to include a constructor, an instance property, and an instance method. Adding these will allow us to create instances of Hello using the new operator: let x = new Hello() We’ll also make Hello store some data, that means our type providers will be one step closer to awesome.

In Part 1 of this series, I briefly explained what a Type Provider was and some of the main concepts which you would need to know. In Part 2, I am going to build a very simple Type Provider. The purpose of Part 2 is to cover the basics of developing Type Providers, how to test them with F# Interactive, and the support tools which make developing Type Providers easy.