F# Community Code Sprint

July 17, 2014

This weekend, Nashville had our first Community Code Sprint. Modeled after the code sprint that NYC held last October, we gathered a group of folks interested in F# (10 of us this time! We had folks even drive in from Georgia and Indianapolis!) and hacked on open source F# projects all day. In the car back from CodeStock (also amazing!) the day before, Tomas Petricek, Paul Blasucci, and I brainstormed a few easy to tackle projects to make sure we had good starting points for anyone who didn’t have a plan on arrival; shortly after arrival and coffee intake, everyone sat down while we reviewed the suggested ideas — and we were off!

I looked first at something I’d been planning to fix for months — support for Mono out of the box for the SQLProvider. I’d hacked together my own version previously and knew it was just a matter of remembering the few changes I’d made. It took a couple hours to get exactly right, but I submitted a PR around noon. :D I next started fiddling with the F# binding for Xamarin, but that’s been a tad more slow finding my way around.

In addition to bunches of bugs fixed in FSharp.Formatting and F# Project Scaffold, we had two other really cool projects come out of the Sprint: Karlkim Suwamongkol’s very cool FsReveal and Luke Sandell’s awesome COM type provider! I highly recommend checking out both of them.

We’re planning to hold the Nashville Code Sprints once a quarter. Hope to see you at the next one!

Rewriting from C# into F#.

June 29, 2013

I know this is almost an old story by now, but it’s the first time I’ve been able to produce any numbers myself. :)

Recently, I rewrote into F# a super simple data transferring app that I’d built for work last fall in C#. There’s not much to it: I grab data from a couple different databases, smash it together in multiple and occasionally bizarre ways, and send it on to its new database home. It’s a perfect use case for F#.


I ran into a couple issues along the way with the SQLEntityConnection and SQLDataConnection type providers.

First, a “mapping of CLR type to EDM type is ambiguous” error. I was using the SQLEntityConnection type provider for all the connections, but Entity Framework doesn’t allow mapping from two databases with any of the same table names.

So, I switched to using the SQLDataConnection type provider. For one database, it worked like a charm. (Progress!) A second one, not so much. I was confronted with somewhere near 680 schema errors. Eeek. After much (MUCH) random flailing about, I discovered that setting StoredProcedures = false for the connections rights everything. I worked out the rest of the code in a few hours this morning. Awesome!


First: during the rewrite, I noticed that I was actually processing tremendously more data than I needed. Heh, oops? This wasn’t as obvious in the C# code, and I’d apparently glossed over it. Going back and fixing this in the C# version actually brought the total processing time down to about 7 minutes (7:14.119 to be exact) from a couple hours.

70% less time!
Second, the longest part of the app, somewhat obviously and by far, was the middle step of processing the data. For the F# version, I used an Array.Parallel.partition to split out and then process what I needed. That, and a couple other details brought the total app time down to nearly 2 minutes (2:24.145.)

25% less code!
Third and finally, I ran a line count in C# (VS shows 140 lines of code, I’m guessing that doesn’t count brackets? Because that seems way too low for 2 projects and 15 total files.) The F# version is 103.

F# is the best ever.

Times, btw, are DateTime.Now differences from the first line of main, until just before the final line is printed to the console. Nothing fancy.

The MIT Study

May 18, 2013

I’ve been trying to blog about this since before “blog” was a word. :)

A long time ago in a state far, far away….

Women In Science and Engineering (WISE)

So, let’s first back up. In college, I was part of this amazing WISE mentoring program, as a math and physics major. We were assigned study groups and had many, many opportunities for mentorship. It was absolutely key to keeping me involved. As part of the program, we were all required to take a certain class — a women’s studies focused on STEM course — which ended with us choosing and then interviewing a woman scientist and writing up a paper on it. I don’t recall if there were more requirements. Being who I am, naturally I couldn’t choose just one; I chose three women to interview:

  • a Physics post-doc, on RHIC maybe(?);
  • a mid-career Chemist at Brookhaven, in charge of her lab;
  • an editor for a prominent Physics journal, who was nearing retirement.

Once I had their stories, I struggled with how to tie them together into a single paper. They’d all contributed an interesting point of view, and one that I wanted to share, but their stories were pretty varied and didn’t seem to flow well together at all. I spent a reasonable chunk of one night in search of research, and found:

The MIT Study

Please go read the whole study, even though I’m paraphrasing. It’s fascinating. :)

How the study came about

  • Three tenured women faculty started a conversation one day, and realized that gender had likely caused distinct differences in their careers, as compared to their male colleagues.
  • They polled the remaining other 12 women in all the departments in the School. Recognition that a problem existed was “instantaneous” amongst most of the remaining women.
  • They requested that the Dean of the School of Science establish a committee to improve the status of the women faculty. The Dean quickly started to champion the cause, and interviews were collected, as well as data on salary, space, resources for research, named chairs, prizes, awards, amount of salary paid from individual grants, teaching obligations and assignments, committee assignments – departmental, Institute, outside professional activities and committees, and pipeline data: numbers of women/men students and faculty over time.

Findings of the Committee

  • The number of women faculty had not changed in at least 10, and possibly 20, years. There was no indication that this number might rise. See Table 2 and Figure 2 for the data on the pipeline leaks at every stage of career.
  • Junior women faculty felt supported, but concerned over balancing work and home lives.
  • Senior women faculty felt “invisible,” and as if they had no power.


An important finding to emerge from the interviews was that the difference in the perception of junior and senior women faculty about the impact of gender on their careers is a difference that repeats itself over generations. Each generation of young women, including those who are currently senior faculty, began by believing that gender discrimination was “solved” in the previous generation and would not touch them. Gradually however, their eyes were opened to the realization that the playing field is not level after all, and that they had paid a high price both personally and professionally as a result.

Back to my paper

After digesting the major findings of the study, I realized that I had interviewed both junior- and senior-level women, and their comments had matched the MIT faculty exactly:

  • the Physics post-doc had commented that it seemed like most of the major work of feminism had already been achieved, and that whenever anyone had a problem with her, she just ignored it; clearly it was *their* problem. She was upbeat and positive.
  • the mid-career Chemist had ranted for a good portion of the time I was with her. She toured me through times she’d undeservedly lost funding, as well as comments other scientists had made to and about her and her work. We discussed the fears and regrets she had, and the backlash she’d faced to speaking up, to fighting for something, and to not behaving how one was expected to behave. She drove home just how much *work* I was in for by detailing some of her personal costs, but she was also torn: she loved her work, and couldn’t imagine doing anything else. It was tremendously illuminating.
  • the Editor had been a practicing scientist for the vast majority of her career. I don’t recall her exact words, but she had stopped practicing her field, in short, because she was tired of fighting constantly. I would refer to her mood as “resigned” for the course of the interview.

It was one of the more depressing moments of my life. I *don’t* want to end up in a non-practicing role. But it was also one of the most empowering, because one result of the MIT study, was that after the committee’s findings were announced, measures were taken to bring the women faculty onto more equal footing. And there were comments like this:

[One] woman, describing the change in her professional life, noted, “I was unhappy at MIT for more than a decade. I thought it was the price you paid if you wanted to be a scientist at an elite academic institution. After the Committee formed and the Dean responded, my life began to change. My research blossomed, my funding tripled. Now I love every aspect of my job. It is hard to understand how I survived those years – or why.”

I have so much more to add, but it will have to wait for a future post. ‘Til then, internet.

VTFun talk on F# Agents

April 27, 2013

Last Thursday, I gave a talk to the most fabulous user group I know ;-) — @VTFun, the Vermont Functional Programming group. We’d previously had a couple talks on actors: one covering Erlang by Dennis, and one on Elixir, by Alan, and the group wanted to know how F#’s actors/agents worked. Seeing as I’d only first heard of actors in December, I spent all last month attempting to devour what I could find.

Here’re some of the most useful articles and videos I found recently.









I am totally planning to post my slides and demos, but wanted to reorganize and rewrite parts first.


Boston Code Camp! And upcoming Community for F# talk!

April 6, 2013

I’m rather late at posting my content from the Boston Code Camp talks, but it was because it was just that much fun I needed the extra time to recover? I’ll go with that option. :)

I gave two talks:

– my Getting Started with F# talk that I’ve given a bunch of times before (VT .NET group, NY F# group, NY Code Camp, Richmond Code Camp, Philly Code Camp) which went over really well. My final example uses the WSDL type provider to grab the local current temperatures, and even though *I’ve* always thought it’s a good sample, it was fun to see it get applause. One audience member even commented they were planning to head to a different talk during the next slot, but that demo convinced them to stick around for the Type Providers talk. Aw shucks. :D

– and my second talk, Consuming Data with F#’s Type Providers. This was only the second time I’d given this talk, but type providers are really an easy win. They’re fun, they’re easy, people <3 them. I’m going to really enjoy giving this talk.

I’ve reorganized my code samples and the powerpoints for both. I’ll leave the old version of the slides for the Getting Started talk on slideshare (link in previous post if you *really* want to see them), but updated versions are with the code samples over on github.

If you’ve not seen the Getting Started talk yet, you’re in LUCK. I’ll be presenting it online for the Community for F# on April 16, noon EST. Details here: http://fpish.net/course/460.  If you miss it, you’ll be able to catch the recording later. I’d love to know what you think about it!

NYC F# User Group Talk

August 3, 2012

Hey, a big thanks to the NYC F# User Group last night for having me! I had some great conversations, and I know a bunch of folks left with a much better understanding of F# and functional programming. I’m just glad I could help!

Just as I’d promised, I’ve posted my samples over on github and the slides over on slideshare. I’d love any feedback you wish to share.


Progressive F# Tutorials

November 6, 2011

I had a bunch of friends attend and tweet about the Progressive F# tutorials this past week. I couldn’t quite instantaneously make it to London for the conference, so I’ve been following up watching the videos (all online, here: http://skillsmatter.com/podcast/scala/fsharp3). Don Syme’s keynote is great, and from what I’ve seen of the rest of the talks, I’d love to be able to head over for the next one. Or have one here!

F# Koans

The other supercool thing I learned about was the F# Koans – Chris Marinos created a project based onEdgecase’s Ruby Koans. The way it works, you’re presented with a project full of failing tests, and you’re required to adjust them to passing. This walks you through very basic examples, and requires you to actually interact with the language. I had tons of fun! It took me a while to finish them all — and I’ll admit I had no end of trouble with the Options one — but I solidified some knowledge & learned a few new things, and I’d recommend them to anyone just starting out! Or not, ‘cause I bet you’ll learn something anyway! ;)

Upgrading Orchard and XML-RPC Error posting with Live Writer

October 15, 2011

I decided to upgrade my blog to the 1.3 version of Orchard last night.

Upgrading to a new version is laid out here: http://www.orchardproject.net/docs/Upgrading-a-site-to-a-new-version-of-Orchard.ashx and is, honestly, very easy. Make backup, install in new directory, copy over a couple important folders, and update modules from the website. And it just works. :)

Ok, well mostly.

I had been in the middle of a blog post (saved locally in Live Writer) when I decided to upgrade. When I returned to the post, finished, and tried to publish; Live Writer would error, with the following:


I was able to re-connect to the blog successfully, and re-download the theme, but it just would *not* publish either a post or a draft. With a bit of searching I was able to find the following (simple) advice on the Orchard forums: copy and paste the post into a “new” post, and you’ll be good to go.

Happy blogging. :)

Another Project Euler problem, and a List.fold example

October 15, 2011

Project Euler Problem #6

Part two in what I hope will be a series on solving some of the Project Euler problems just to learn F# (part 1 here).

I skipped down to #6 next, and was able to whip out a few lines of F# pretty quickly to get the answer. Since I was just re-using List.sum and List.map, there wasn’t much new here.

   1:  let numbers = [1..100]
   2:  let squares = numbers |> List.map (fun x -> x*x)
   3:  let sumsquares = List.sum squares
   4:  let sums = List.sum numbers
   5:  let squaresums = sums*sums
   6:  let total = squaresums - sumsquares

Then after a short chat with Richard Minerich, whose blog post on getting started gave me the idea to work on the Project Euler problems to begin with, I decided to condense this a bit. I was able to pretty quickly rewrite lines 2 and 3, and 3 and 4 into:

   1:  let sumsqaures = numbers |> List.map (fun x -> x*x)|> List.sum
   2:  let squaresums = numbers |> List.sum |> (fun x -> x*x)

Around this point, I found Dustin Campbell’s #6 solution, which helped me realize the teensiest (but ridiculously major) thing that you can replace:

   1:  (fun x -> x*x)

with a new square function:

   1:  let square x = x*x

and just call that, instead. Also, there’s no reason not to condense the subtraction to one line – except maybe readability :p – so I end up with:

   1:  let numbers = [1..100]
   2:  let square x = x*x
   3:  let total = (numbers |> List.sum |> square)-(numbers |> List.map square |> List.sum)

Fun! I decided to stop there, and not continue to what ultimately would have been pretty close to his solution (check it out, it’s delightful) because that felt somehow like accidental cheating. :)

List.fold Example

Since #6 was a little easy, I thought I’d add a small thing – I was flipping through Chris Smith’s Programming F# this afternoon, and saw that both he and Chris Ammerman (in the comments last night) provided the same example: using List.fold to take an array of strings into a single comma-delimited string (must be a people-named-Chris-thing to come up with that example.. *shrug*). You can see Chris Smith’s code from the bookhere. Thanks for helping me make sense of that one, folks. :)

Project Euler problems with F#

October 10, 2011

Since I’ve just – JUST – started learning F#, I thought I would post my solutions to the first couple problems on Project Euler:

Problem #1: Add all the natural numbers below 1000 which are multiples of 3 or 5.

   1:  let all = [1 .. 999]
   2:  let filtered = all |> List.filter (fun x -> x%3=0 || x%5=0)
   3:  let count = List.sum filtered

So, first we declare a list of all natural numbers (basically, positive integers, since it doesn’t matter here if 0 is included or not) less than 1000. Then, we take that list and filter it for everything that’s divisible by 3 or 5. And finally, sum the list. Pretty easy. Now that I’ve done it. :)

Problem #2: Find the sum of the even-valued terms of the Fibonacci sequence which are less than 4 million.

   1:  let fibSeq = Seq.unfold (fun (a,b) -> Some( a+b, (b, a+b) ) ) (0,1)
   2:  let fibList = fibSeq |> Seq.takeWhile (fun x -> x<4000000 ) |> Seq.toList
   3:  let filterList = List.filter (fun x -> x%2=0) fibList
   4:  let fibSum = List.sum filterList

By far the hardest part about this problem (for me) was figuring out how to create the Fibonacci sequence. This whole unfolding thing is *totally* new. Basically, you’re starting with (a=0,b=1) and applying (a+b, (b, a+b)) for each new element. Once we have the generating function defined, we send that to takeWhile to only grab values less than 4 million, and put those into a new list. Next, we filter the new list, for only even values. Finally, sum those up.

I would *love* feedback on the code. Or how have you done it? I only went back a couple pages, but I didn’t see a single other F# solution in the forum for those two questions!

Also, a (probably very basic) question: I’ve seen several examples where people use List.fold to sum things. Since List.sum exists, would you ever do that IRL? When *would* you use List.fold? I haven’t been able to quite wrap my head around it. Thanks!

Powered by Wordpress and MySQL. Theme by Shlomi Noach, openark.org