Results tagged “F#”

Everybody that's interested in F# has played around with some code, and it's amazing how much stuff you can put into a small space with the language, but at some point, you're probably going to get into a situation where you have more than one source file, yet you'd still like to stay functional.

So here's a suggested structure outline for those larger functional projects

A funny thing happened to me over the past two years of playing around with F#.

Programming became fun again.

The more I play with F# the more fun it gets. Take for instance this problem I was having last week.

I have been playing around with F# for over a year now, and I really love it. I *think* I have most of it mastered, except maybe active patterns and workflows -- but I'm getting close to groking those. Recursion still makes me scratch my head for a bit, but I can recurse with the best of them once I get going.

What sucks is running into bugs -- not mine, but the compiler's. Here are two I ran into last week that's caused a lot of pain (and information about a possible third one)

I'm building a new startup -- it allows people to collect and share quotes from books and web articles. As you add each quote, you tag it. When people vote up or down your quote (or comment on it), the system trains itself to learn which tags each user likes. I may like quotes from American History. You may never want to see any quotes about politics. Over time, the system learns this and acts accordingly. That way you can have a broad range of subjects with a large user base and the app still has the feel of a private forum.

A while back, Paul Graham wrote a language called Arc. After he wrote it, he challenged other languages to create a simple set of web pages in as few tokens as possible. In Paul's philosophy, the fewer tokens a language has (or needs) the more robust it is. Therefore the more likely it is to last a hundred years

I've been thinking about Paul's assertion for over a year now. I've programmed in lots of languages -- to me they're just tools. Old friends. I can't say I am crazy about one language or another, no matter how many tokens it has.

As I and others pointed out, you can make a computer language do almost anything in as few tokens as you like as long as you've set up a DSL (Domain-Specific Language) for the problem domain.

Since I'm building my product almost from scratch, I thought I would take you through a quick tour of how you end up with powerful "languages" that have maximum expressiveness and minimum tokens, no matter what tools you are using. For this discussion, we'll stick to a (mostly) .NET stack, with some major modifications, but the stack is really not important.

Continuing with the F# TDD fun...

So far everything's hunky-dorey, but F# is all about terse code and writing functions that then grow into systems. While xUnit lets us test a little easier, we're still stuck with a lot of overhead. Can we tighten this up a bit?

First let's tweak a couple of the xUnit methods a bit so they read better and we can use piping.

It's a nit, but little rewrites like this can help

So will F# testing be the same way?

"You've got to be very careful if you don't know where you are going, because you might not get there. " - Yogi Berra

Some things are so easy they're idiot-proof, but then along comes a better idiot to prove you wrong.

I was thinking about this today as I set up Visual Studio, F#, and Xunit

Since I thrashed around for about an hour and shouldn't have, I thought I would make an easy 1-2-3 cookbook for setting up F# and TDD.

So far my experiment in programming in F# has been an unmitigated disaster. Not that I have killed myself trying -- I simply thought that you installed the language and everything would work. Turns out it is not-that-ready-for-prime-time.

Ready for prime time?

I've gotten the functional programming bug lately. Most of my career after I learned my third language or so, I could care less what the language is -- just let's solve it already, ok? But lately I've been hearing the functional programming wonks go on, quite at length, over how great functional and meta-programming is compare to common, pedestrian programming.

I'm not drinking the cool-aid yet, but what the heck -- let's fire up Microsoft's new F-Sharp language and take a quick look under the hood.