Fsharp

Ive been meaning to write this post for ages but Ive only just found the time.

On the 3rd of September my good friend Ryan Riley (aka @panesofglass) emailed me letting me know I had won a Community for F# hero award for 2015!

I’ve finally been awarded a Microsoft MVP its been quite a long time coming. Ive been nominated for MVP every year since July 2011 but until now I have been unsuccessful. On the 1st of July I received an email congratulating me that I had been successful on my MVP nomination.

Sit down, strap in, and prepare for take off, we’re going Meta-Matic!

Did you know there was more to the type matching operator than just pattern matching and exception handling?

So this is my Christmas special. I’ve been asked on numerous times to write about the F# addin for Xamarin studio which is in the fsharpbinding repo, this repo is shared with the emacs support and also the Sublime Text support. So in this edition we will be taking a deep dive into the terrifying deep depths of the F# compiler and F# addin development…

While I was visiting Boston earlier in the year I had the misfortune of kicking myself in the teeth with reflection. It’s something all programmers inevitably go through with reflection API’s as they are inherently untyped, a simple typo can leave you tearing out your hair or punching through your monitor! Yeah there’s things the horizon that will help namely the nameof expression in C#6 which should help in some areas, that’s if your willing to pay the price of using C#, but I wont go into that here :-). In F# we can leverage Type Providers fairly easily to wrap API usages in cases that we are interested in, or even create a general usage with a little more effort.

First of all the title, redux because I’m revising post I started on earlier in the year, compression because this has to do with compression, and Flux, which is also part of the redux, one of the first things I remember writing on the net was an article about Flux Compression Generators on H2G2, its still there too!

This was a post I started writing back in January that I never got round to finishing.

For any of you that are aware of the newly updated Xamarin Web site, you may have seen the following:

Objective-C was ahead of its time 30 years ago. C# is ahead of its time today. Anything you can do in Objective-C or Java, you can do in C# with Xamarin—usually more succinctly and with fewer bugs.

What is also true is that F# is way ahead of its time, and you can produce even more succinct code with even fewer bugs than C#!

With the release of Xamarin 3 there is a swathe of new features to the platform, but obviously the most important one is obviously F# support is now included by default in Xamarin Studio so there is no escape from the awesomeness of F#!

So what else have we got, well loads of other goodies too like Xamarin Designer for iOS, Xamarin.Forms, Major IDE enhancements, Improved code sharing with PCL and Shared projects, and BCL Documentation. You can see the release blog post here: announcing Xamarin 3

Over the last year a lot of work has been done on the F# addin for Xamarin Studio. Lots of great new features have been added and a lot of bugs have been squashed. I want to talk a bit about whats been happening and the evolution of the F# addin.

The F# addin for MonoDevelop / Xamarin Studio hasn’t always been as stable and pretty as it is now. When I first started working on it I went through a rocky phase of just trying to get it to compile and install. There were a whole host of changes going on in MonoDevelop which caused a lot of head scratching and late nights. Of all the issues encountered tooltips were the absolute bane of my life, they were often horribly mangled like this:

Only a quick post this week. Last time we looked at SpriteKit and how to add some particle emmiters to simulate a star-field and exhaust on a spaceship, this time lets look at adding some touch based input to move the spaceship around.

The first thing we need to do is add a type of gesture recogniser, there are various built in gestures:

• UITapGestureRecognizer
• UIPinchGestureRecognizer
• UIRotationGestureRecognizer
• UISwipeGestureRecognizer
• UIPanGestureRecognizer
• UIScreenEdgePanGestureRecognizer
• UILongPressGestureRecognizer

From the names above it’s pretty easy to get a feel for how they should be used, you can create your own subclass of UIGestureRecognizer if you need a custom one.

I have been meaning to write this post for quite a while now. Since the first announcement of the iOS7 beta I immediately saw the list of new API’s and SpriteKit caught my eye straight away. I only managed to get time to briefly look over the API and saw that is wasn’t the usual trashy API with a million method overloads, internal mutation sucker punch type thing. It seems to be very declarative and intuitive, which makes for a nice change.