in

ExpressionBlog.com

Microsoft Expression Studio Community

This Blog

Syndication

Mirrored Blogs

Browse by Tags

All Tags » Functional Programming (RSS)
  • Functional .NET - Fighting Friction in the BCL with Directory.GetFiles

    Very recently on a project, I was having significant issues with System.IO.Directory.GetFiles, in which I was getting an access denied message which prevented further crawling of certain directories.  The performance issue was another issue that was detrimental.  I wasn't happy either with the design of this API.  Instead, I set out to fix some of these issues and come up with a design that I felt better addressed some of my concerns with some techniques from functional programming.   The Issues There are several issues that lead me to come up with an alternative for this situation of getting all files in a directory.  Arrays shouldn't be returned from method calls Processor intensive for iterating over large directory trees instead of calculating only what I need, when I need it Filtering is weak, and only uses file format patterns Access denied internal messages occur for no apparent reason which halts the method Let's talk about each just a little bit more. The first issue with GetFiles is that it returns an array.  Eric Lippert , of the C# team recently posted on "Arrays considered somewhat harmful" , in which he describes that for most cases, arrays should not be used in one form or another.  In this post, he states: You probably should not return an array as the value of a public method or property , particularly when the information content of the array is logically immutable. Let me give you an example of where we got that horridly wrong in a very visible way in the framework.  If you take a look at the documentation for System.Type, you'll find that just looking at the method descriptions gives one a sense of existential dread. One sees a whole lot of sentences like "Returns an array of Type objects that represent the constraints on the current generic type parameter." Almost every method on System.Type returns an array it seems.   Given that the GetFiles method returns an array, we could feel free to mutate the contents of this array and we'd be none the wiser for it.  There is no need, once calculated, to change this value.  This file path is what it is.  If you need to modify the contents, a Map (Select) would do wonders if you are using an IEnumerable<string> instead.  The problem with arrays is that they are a big bucket of mutability.  Coming from the functional programmer standpoint in me, I don't like that as an option, and would rather have an immutable List<T>.  Secondly, there are performance implications of recursing through large directories all at once.  It's very much a blocking call in the application.  Another key point in the functional programming world is to only calculate what you need, aka just-in-time computing.  If I'm not going to immediately use all items in this array, I just calculated all files for no apparent reason.  So, there is a big plus when returning...
  • Functional C# - Implementing Async Computations in C#

    As I covered earlier in my post Functional .NET - LINQ or Language Integrated Monads , I talked about using asynchronous computation expressions (monads) from C# 3.0.  Brian McNamara , of the F# team, posted back in May about using them from C #.  But since then, things have changed slightly.  Before, I showed a basic example of how to utilize the F# libraries from C#, but let's go deep under the covers to see how this actually works.   Getting Started In order to make use of the F# libraries in our C# library, we need to add references to them.  We need the following items: FSharp.Core.dll FSharp.PowerPack.dll FSharp.PowerPack.Linq.dll And then I need to open the namespaces in order to take advantage of F#: using Microsoft.FSharp; using Microsoft.FSharp.Control; using Microsoft.FSharp.Core;   Referencing F# Classes As part of process of creating the asynchronous monad builders in C#, we need to create an instance of the F# class AsyncBuilder in the Microsoft.FSharp.Control namespace.  Unfortunately, the AsyncBuilder has an internal constructor, thus preventing us from creating it directly.  The other option is getting the async instance in the AsyncImpl internal class.  I think the first option is a bit more preferable.  In order to create an instance, all we need to do is invoke the constructor via reflection as a static instance. static   class AsyncExtensions {     public   static AsyncBuilder async = CreateAsyncBuilder();     private   static AsyncBuilder CreateAsyncBuilder()     {         var asyncType = typeof (AsyncBuilder);         var ci = asyncType.GetConstructor(             BindingFlags.Instance | BindingFlags.NonPublic,              null , new Type[ 0 ], null );         var result = ci.Invoke( null );         return result as AsyncBuilder;     } ...   Now that we have this, we have to realize that F# doesn't use the standard .NET delegates for functions.  Let's walk through some ways of converting back and forth.   Converting Functions As we've noted before, F# does not use the standard Func and Action delegates that are commonly used in C# and VB.NET.  Instead, the functions in F# use the FastFunc class.  This allows for the F# compiler to better optimize the closures, especially due to the fact that these closures are quite commonly used.  Another point of difference is that there is no distinction between Func and Action delegates, and instead, for functions that return no value have the return type of Unit.  This is the optimal way of handling this, due to the fact that Void is not treated as a real type, which...
  • Functional .NET - LINQ or Language Integrated Monads?

    As part of my talk at the Richmond Code Camp earlier in October, I had the opportunity to talk about how to implement functional aspects in C# 3.0.  This talk revolved around such concepts as from mutable to immutable, from inheritance to functional composition, and the mind shift that is required.  Part of this discussion involved very briefly a talk about monads.  It's a very misunderstood part of computer science and one of the most powerful concepts to learn.  Much like continuation passing style, this style is often maligned as a result.  But, let's work to change that.   What Is a Monad? Monads come to us originally from category theory.  When monads applied to functional programming, they simply are a construction, given an underlying type system, embeds a corresponding monadic type system.  Simply put, the values you have become amplified values that are to be interpreted by the matching monadic type.  The formulation of a monad comes in three parts: A type construction that defines for every underlying type, how to obtain a corresponding monadic type.  If the given type in F# is 'a, then the corresponding monadic type for an Identity monad would be I<'a>.  I'll cover more of what that means below. A unit function that maps the underlying type to a value in the corresponding monadic type.  In F# parlance, this maps to a Return function. A binding operation of polymorphic type, in F# parlance, (I<'a>) => ('a => I<'b>) => (I<'b>).  This maps to a Bind function given your monad builder.  If you look carefully at the signature of this, you might also note that the LINQ SelectMany follows this syntax.  Gee, what could that mean?  The bind operation follows four steps: The monadic structure exposes the underlying value of type 'a. The given function is applied to the underlying value to obtain values of type I<'b> The monadic structure exposes the underlying value of type 'b. The monadic structure is reassembled over the results, given a single value of type I<'b> Simply put, a monad, unlike your normal function results, stores function results and side-effect representations. This allows side effects to be propagated through the return values of functions without breaking the pure functional model.  This is what makes it so powerful that it is a way to manage side effects.  Given a pure language such as Haskell, this is the way that any side effecting operation should be done.  Granted, there are impure ways of doing IO, but let's not go there. There are some good sources of information on what monads are, including some great stuff from Brian Beckman: Channel9 - Brian Beckman: Monads, Monoids and Mort Channel9 - Brian Beckman: Don't fear the Monads Wes Dyer - Marvel of Monads Some examples of monads that are used frequently are such things as the...
  • Richmond Code Camp 2008.2 - Functional C# Recap

    Thanks to everyone who attended my session "Functional C# or how I lost the foreach and learned to love LINQ".  This is still an ongoing passion of mine that I hope to expand upon in the upcoming posts.  Some of these topics include favoring functional composition over inheritance and implementing patterns such as the Specification Pattern using these techniques.  I'll be posting all code snippets from the functional posts up to date on the MSDN Code Gallery Functional C# Project . Here are some resources that will be helpful in covering functional programming aspects as well as other topics covered: Functional Programming Why Functional Programming Matters - John Hughes Why Haskell Matters F# Home Page C# Futures Is C# Becoming a Functional Language? - Mads Torgersen C# 4.0 : Meet the Design Team Anders Hejlsberg and Guy Steele on Concurrency and Language Design Functional Programming Aspects with C# Functional C# - Into the Great Void Functional C# - Unfolding Lists Functional C# - Learn from F# and LINQ Functional C# - Pattern Matching Recursion in C# Part 1 - Basic Recursion Techniques Part 2 - Recursing into Linear, Tail and Binary Recursion Part 3 - Recursion on Lists Part 4 - Recursing into Recursion - Memoization Part 5 - Continuation Passing Monads The Marvel of Monads - Wes Dyer Don't Fear the Monads - Brian Beckman Monads, Monoids and Mort - Brian Beckman Spec# Spec# Home Page Hanselminutes Episode 110 - Spec# with Rustan Leino and Mike Barnett .NET 3.5, Design by Contract and Spec# Books LINQ in Action Pro LINQ Expert F# Podcasts Software Engineering Radio Episode 108 - Simon Peyton Jones on Functional Programming and Haskell Software Engineering Radio Episode 97 - Anders Hejlsberg Software Engineering Radio Episode 72 - Erik Meijer on LINQ .NET Rocks Episode 310 - Simon Peyton Jones on Functional Programming and Haskell .NET Rocks Episode 270 - Erik Meijer on LINQ As I said before, I'm making the code available as I put it up on MSDN Code Gallery as the FunctionalCSharp project .  This is intended to be a library of functional programming techniques in C# 3.0 and some demonstrations of moving from imperative style programming to a more functional programming style.  This is an ongoing project and more will be added in time, and I may end up just putting them up not as samples, but as a library. Some of the topics covered in these code projects are: Closures Currying Filter High Order Function Fold High Order Function Iterators Lazy Evaluation LINQ Lists (Immutable and Recursive) List Comprehensions Map High Order Function Memoization Monads Operators (Forward, Reverse, etc) Recursion Unfolding and Generators As always, my code snippets can be found on MSDN Code Gallery at the Functional C# Library .
  • ASP.NET MVC with NHaml - F# Edition

    As part of some of my adventures with F#, I've seen a lot of interesting things coming from others with regards to SharePoint, ASP.NET and other technologies. This had me thinking of any possibilities and ramifications of using F# with ASP.NET MVC. Was it possible, and better question, what might make someone use this over their existing toolsets. Those are some of the questions to explore. But, in the mean time, let's take the journey of F# and ASP.NET MVC. Getting Started First, let's cover what it takes to get F# to work with ASP.NET MVC. The required downloads are: F# September 2008 CTP ASP.NET MVC Preview 5 MVCContrib for ASP.NET MVC Preview 5 Side by side, I think it's easier to first create a sample C# ASP.NET MVC project, so it's easy to cut and paste the configuration file information. What works better is to open the NHamlViewEngine sample from MVCContrib. Also, create a standard F# library, and in my case, I called it MvcFSharp. I then add references to the following assemblies: Microsoft.Web.Mvc.dll MvcContrib.dll MvcContrib.NHamlViewEngine.dll System.Web.dll System.Web.Abstractions.dll System.Web.Extensions.dll System.Web.Mvc.dll System.Web.Routing.dll Since the F# projects do not support creating folders, this next step requires some Visual Notepad support. Modifying the Project File First, create the Models, Controllers, Content and Views directories through Windows Explorer. Create dummy files in each folder is probably the easiest thing to do. When you are done, your project file contain this: < ItemGroup > < Compile Include =" Models\ListViewData.fs " / > < Compile Include =" Controllers\HomeController.fs " / > < Compile Include =" Default.aspx.fs " > < DependentUpon > Default.aspx < / DependentUpon > < SubType > ASPXCodeBehind < / SubType > < / Compile > < Compile Include =" Global.asax.fs " > < DependentUpon > Global.asax < / DependentUpon > < / Compile > < Content Include =" Default.aspx " / > < Content Include =" Global.asax " / > < Content Include =" Content\Site.css " / > < Content Include =" Content\MicrosoftAjax.js " / > < Content Include =" Content\MicrosoftAjax.debug.js " / > < Content Include =" Content\MicrosoftMvcAjax.js " / > < Content Include =" Content\MicrosoftMvcAjax.debug.js " / > < Content Include =" Views\Home\About.haml " / > < Content Include =" Views\Home\Index.haml " / > < Content Include =" Views\Home\Numbers.haml " / > < Content Include =" Views\Masters\Application.haml " / > < Content Include =" Web.config " / > < / ItemGroup > In this actual case, these are the real files listed for our first F# ASP.NET MVC application. Once you reload the project file from Visual Studio...
  • Object Oriented F# - Creating Classes

    In the past couple of posts, I covered extension everything in F#.  This allows me to extend .NET types with such things as extension static and instance methods, properties, properties with indexers, events and so on.  But, let's go back to the beginning and cover object oriented programming with F# from the ground up.  I like to stress that F# is not only a first class functional language, albeit a more impure one than say Haskell, but it also treats imperative and object oriented code as first class citizens as well.  To be able to mix and match for the appropriate programming style makes this a very powerful tool, to be able to use functional aspects with first class citizenship, but as well with imperative and object oriented, well, then the sky is the limit.  With that, let's go over some of the things that make F# a player in this space. Let's get caught up to where we are so far: Part 1 - Extension Everything Part 2 - More Extension Everything Defining Classes As I will point out several times, F# is a pretty flexible language.  With this, you will find that there are several ways of defining classes, whether it be explicit constructors, constructors in the type definition among other things.  Constructed classes in F# must follow the sytanx, with those items in the brackets being option, and the ones with the asterisk may appear zero to many times. type TypeName optional-arguments [   as ident ] =   [   inherit   type   {   as base }   ]   [   let -binding |   let - rec bindings ] *   [   do -statement ] *   [   abstract -binding |   member -binding |   interface -implementation ] *   From the above syntax, I can specify the inheritance, local functions and values (let syntax), verify parameters with the do syntax and member properties, methods and interface implementations.  Defining a simple class is very straightforward.  Consider if I want to implement a person class and override the ToString() to output some meaningful input.  The code for implementing this is compact without a lot of pomp and circumstance such as this. type Person = { FirstName : string ; LastName : string ; Age : int   }   with   override x . ToString ( ) =     sprintf "%s %s is %d years old" x . FirstName x . LastName x . Age        let p1 = { FirstName = "Matthew" ; LastName = "Podwysocki" ; Age = 31   } printfn "%s"   ( p1 . ToString ( ) ) What's nice about this approach is that I can define these simple classes and once they are constructed, they are immutable by default.  Very nice for message construction and other operations.  But, if you want more behaviors inside your defined classes, then it's best to use a more explicit syntax as below. Constructing Classes Using the construction style...
  • Herding Code Episode 18 - Functional Programming and F#

    A couple of days ago, I had the pleasure of recording Episode 18 of Herding Code on Functional Programming and F#.   The topic on their minds was around functional programming, and more in particular with some of the things I've been doing around the .NET space both C# and F#.  Some of the things I talked about in this episode were around the following topics: What is Functional Programming and why should we care? C# and the evolution of the language with functional aspects and where it falls short What is F# and what is the value proposition? Some of the uses of F# I had a lot of fun doing this episode and I hope it shows!  Feedback is always appreciated.
  • Functional C# - Pattern Matching

    In the past, I've covered quite a bit of functional programming in C# 3.0 and how you can implement some of the basic constructs using the language.  In preparation for the Richmond Code Camp coming up on October 4th, for which I'm planning to present "Functional C# -or- How I lost the foreach and learned to love LINQ", I'm revisiting some of the topics I've talked about in the past.  One of those topics is pattern matching . Pattern Matching Earlier in my introduction to F# series, I covered pattern matching and how clear and concise it can make your programs.  You can more program to your intent instead of needing to switch between if statements, case statements and so on.  Basically, pattern matching is the way of checking for conditions on a given parameter with rigid specifications.  Pattern matching is a strongly functional programming concept and is present in F#, OCaml, Haskell, Erlang, etc.  Erlang is an interesting one here as you can define the patterns, which in turn will define the type.  As Erlang is a dynamic language, you do not need to specify the type beforehand, so implementing patterns then define that type. Pattern matching in F# is pretty flexible as it allows to match against explicit values, structures, lists, guarded ranges, .NET types, active patterns and so on.  The basic syntax is match ... with ... expressions such as this. match expression with | pattern_1 -> expression_1 | pattern_2 -> expression_2 | pattern_n -> expression_n   Similarly, I could use the function keyword should I create a function with the parameter to pattern match against instead of the above syntax, such as this. let get_value = function   | None ->   0   | Some n -> n let value = get_value ( Some 25 ) As you may notice, F# has very flexible syntax for describing these, so let's look at a few more ideas before we move on. Data Structure Matching We can pattern match against data structures, such as lists quite easily.  Lists are a special case as it allows you to match against the head and the tail of the given list.  By using the head::tail notation allows us to specify that we will receive the head and tail values should they be present.  Such an example might be to get the evens from a given list. #light let   rec even_list = function   |   [ ]   ->   [ ]   | h : : t when h % 2 = 0   -> h : : even_list t   | h : : t -> even_list t let evens = [ 1 . .20 ]   | > even_list   Active Patterns Pattern matching in F# is extremely flexible, as you can extend what you can pattern match.  Through a mechanism called "Active Patterns", you can extend the syntax quite easily.  Let's say for instance that we want to create a pattern to determine whether a given number is either a composite number, prime number or neither.  We can define a pattern over...
  • Object Oriented F# - More Extension Everything

    In a previous post , I covered a few ways we can do extensions methods, properties, events and so on with F#.  After a few chats, I realized I may have missed a couple of cases that I wanted to cover today.  These two cases are extension operators and extension properties with indexers. With these examples, I'll try best to show you my development style, using my FsTest library from CodePlex to set up my expectations of the extensions using F# syntax.  If you're not familiar with FsTest, I recently updated it to support the F# September 2008 CTP . Extension Properties with Indexers One of the common things we like to have with some of our collections is the ability to retrieve the item by index, using the Item or this property.  With such classes as IEnumerable<'a> among others don't support such a construct, but through the use of extension properties with indexers, they can.  Let's set up how our test should be. #light open Xunit open FsxUnit . Syntax open ExtensionFSharp . CollectionExtensions [< Fact >] let items_with_correct_index_should_be_equal ( ) =   let items = { 0   . .   2   . .   100 }      let actual = items . [ 3 ]   let expected = 6   expected | > should equal actual   What I'm going to do is create a collection of 0 to 100 skipping every two numbers.  I will set my expectation that the third item should be six, which should be easy enough to test.  Running this test of course will not work as the extension property isn't defined yet.  Now, let's go ahead and define what that might look like. #light namespace ExtensionFSharp module CollectionExtensions =   type System . Collections . Generic . IEnumerable with          member this . Item       with get ( index ) =         Seq . nth index this   What I was able to do is open the type definition of IEnumerable<'a> and add the Item property, also called the this property in C#, with a get accessor with an index.  This calls the Seq.nth which is a static function on the Seq module to return the item that I want by index.  Now, I can run my test again and check the result. Just the result we were looking for.  We could go ahead and add additional tests for out of range and inequality, but in the mean time, let's move onto another way of extending F# and the language through operators. Extension Operators One of the more interesting ideas is around extension operators.  This would give us the ability to add additional operators to our classes should we feel that they should support add, subtract and so on.  To me, it's a pretty powerful concept to be able to add such things.  Let's set up our test to see how we think it should look. #light open ExtensionFSharp . DrawingExtensions open Xunit open...
  • Side Effects and Functional Programming

    One of my first posts at CodeBetter was in regards to side effects and how, when unmanaged, can be truly evil.  Today, I want to revisit that topic briefly in regards to functional programming and managing side effects.  When I was out in Redmond a couple of months ago, I had the opportunity to sit down with Erik Meijer to discuss functional programming among other topics.  In there, we discussed a number of issues around managing side effects and state in your code, and how both C# and F# don't intrinsically support such a concept.  Languages like Haskell, of course do with IO monads and other such monadic structures.  Whether languages such as F# and Erlang are hoaxes as functional programming languages is another matter, due to the fact that you don't have to declare when you are side effecting (reading a database, writing to console, spawning a process, etc).  Erik recently gave a talk called "Fundamentalist Functional Programming" in which he is not shy about his beliefs that nirvana lies in a more functional style, and side effects are declared and managed.  In this post, I want to go over just a few of the ideas expressed, because I'm wholly on board with this notion.  The Problem of Purity In some previous posts, I talked about function purity in regards to things you should keep in mind with a functional mindset.  In order to qualify as such, you need to meet the following criteria: Evaluate with the same result given the same input, and perform no state change. Evaluation of the given function does not cause observable side effects (write to console, write to database, etc) Things get even more clouded as we bring lazy evaluation to the table.  One of the great things that came to C# in 2.0 and especially in 3.0 with LINQ was the idea of lazy evaluation through the yield keyword.  This gave us the ability to defer work until it was absolutely needed.  That's one of the hallmarks of functional programming, especially a lazy language such as Haskell. Let's look at a code snippet both written in F# and the equivalent in C# and let's determine the order of side effects.  Can they be predicted here?  When do the side effects happen?  Do I just get a nice list of my integers at the end? F# #light let divisible_by_two n =    printf "%i divisible by two?" n   n % 2 = 0 let divisible_by_three n =   printf "%i divisible by three?" n   n % 3 = 0    let c1 = { 1   . .   100 }   | > Seq . filter divisible_by_two let c2 = c1 | > Seq . filter divisible_by_three c2 | > Seq . iter ( fun c -> printfn "%i" c ) C# static   bool DivisibleByTwo( int n) {     Console.Write( "{0} divisible by 2?" , n);     return n % 2 == 0 ; } static   bool DivisibleByThree( int n) {     Console.Write( "{0} divisible...
  • Object Oriented F# - Extension Everything

    A post by Jeremy Miller caught my eye this morning in regards to extension methods in Javascript .  While I think that's pretty interesting, I don't think it's a real fair comparison.  Instead, I want to revisit C# and even F# with regards to extension methods, because there are a few things I wanted to point out.  This is the start of a series covering object oriented programming techniques and how they are used in F#.  Note that F# is not only a functional language, but it is a general purpose programming language that supports functional, imperative and object oriented techniques.  I hope this series is useful for pointing out that F# fits the need very nicely for object oriented constructs, which is seldom covered. Extension Methods in C# 3.0 With C# 3.0 came the introduction of extension methods which were introduced as part of certain technologies that were LINQ-enabling.  Using these, we could add methods, and only public methods, to any given class we choose.  So, this gave us the ability to do add methods such as ForIndex to an IEnumerable<T> class such as this: static   class Extensions  {      public   static   void ForIndex<T>(       this IEnumerable<T> items,        Action< int , T> action)      {          var index = 0 ;          foreach (var item in items)          {              action(index, item);              index++;          }      }  }  var range = Enumerable.Range( 1 , 10 );  range.ForIndex((i, item) => Console.WriteLine( "{0} - {1}" , i, item));   But overall, I thought this was nice, but didn't go quite far enough.  Why not extension static methods, properties, events, etc?  I'm sure at one point those were considered but somehow dropped along the way, and I think it's a shame quite frankly.     Where should it be?  If this functionality were to exist in C#, how might it look?  Unfortunately, the way it was designed in C# 3.0, it makes it a tad hard to extend for static methods and properties.  For example, how might you declare a get or set if what you're declaring is a method such as this? public   static   bool IsEven( this   int value) {     get { return value % 2 == 0 ; } }   Or if I were to use the property declaration style instead, it seems just as confusing as the above try at this: public   static   bool   this   int IsEven {     get { return   this % 2 == 0 ; } }  ...
  • FsTest Updated with F# CTP

    Back in June, I announced the creation of FsTest , a testing Domain Specific Language for F#.  Since that time, the F# team has released the September 2008 CTP, which finally gives F# full citizenship within Visual Studio with real project files.  I felt it was time to update FsTest, and more in particular, FsxUnit, which uses xUnit.net as the back end for doing assertions.  Go ahead and pick up the latest bits here from the CodePlex site . What's Changed? Other than migrating the code to the new F# project formats, the migration was rather smooth.  As I have mentioned before, order still matters in your F# projects.  But luckily Visual Studio now gives you the opportunity to not only add files above and below, but to move files up and down as well, as shown below: Code changes were pretty minimal.  There were a few instances in which I had to change the method signature slightly in the interface file, such as the following. Before /// Determine whether the collection is empty val Empty :   # System . Collections . IEnumerable -> unit After /// Determine whether the collection is empty val Empty : System . Collections . IEnumerable -> unit The difference between the two being that the before has a signature which looks like this: val Empty<'a when 'a : > System . Collections . IEnumerable>   And having it specified that way does not work properly, whereas it did in the previous versions of F#.  There were several instances I removed the # in front of the seq and IEnumerable classes.  Note that none of the calling code in any of my tests had to change one bit, so if you've been using it, there should be no issues arising. Since the time I unveiled FsTest, xUnit.net , my favorite unit testing framework, has released version 1.02 , which covered minor bug fixes.  After updating the references and fixing those slight issues, I'm able to run the xUnit.net GUI runner and get the green lights which is always joy: Where to Go From Here? So, where do I go from here?  I'm still looking to move this more towards a BDD style, instead of just the DSL syntax for the assertions.  Taking some ideas still from RSpec and Scala Specs is my goal to make this a more complete solution.  It's still a work in progress, but the real question, what works for you?  What doesn't?  Where should it go?  I have some ideas, but feedback is always appreciated.
  • Functional Programming Notables #1

    Lately, there has been a lot of momentum around functional programming. While I was away on vacation for the past couple of weeks, I came across quite a few items that caught my eye. This isn't meant to be a link blog by any means, but to show that there is a bit of new information coming out around functional programming and what it means to you. F# There has been a bit of excitement around F# since the release of the September 2008 CTP . If you haven't already downloaded it, I'd highly encourage you to do so. With that, there are a few more items coming out on the horizon worth checking out: F# for Scientists - Jon Harrop Dr. Jon Harrop, the owner of Flying Frog Consultancy, has released his F# book, F# for Scientists. This book comes at the angle of a computationally oriented researcher, scientist or developer that wants to learn functional programming. This book not only covers the functional programming aspects of F#, but the object oriented and imperative as well. I've ordered this book and can't wait to get my hands on it. I plan to do a review once I have. Ted Neward and Amanda Laucher on .NET Rocks Both Ted and Amanda will be on .NET Rocks on 9/16 to promote their book, F# in a Nutshell . There are quite a few more books on F# and don't be surprised to see some more announcements soon on the subject. Haskell Haskell is a language that I've been learning lately on the side. I haven't posted much on this here on this blog, but maybe at some future point I will compile some links to help you get started. Some of the re-interest on my part has actually come from Michael Feathers and his tweets on Twitter . Lately, Haskell has been gaining traction, even to the surprise of Simon Peyton Jones . Much of the interest arises from the concurrency angle in regards to language enforced purity. Anyhow, a few items caught my eye in regards to the Haskell community: Software Engineering Radio Episode 108 - Functional Programming and Haskell Simon Peyton Jones, one of the main contributors behind the Glasgow Haskell Compiler, and esteemed researcher at Microsoft Research recently appeared on Software Engineering Radio to explain functional programming and Haskell. Software Engineering Radio tends to be one of my favorite podcasts as they are quite technical and in-depth in the interviews. This is a great episode and great listening! He also appeared recently on .NET Rocks Episode 310 as well. Real World Haskell I've been following the progress of Real World Haskell for a little bit now. The goal of this book will be to explain not only Haskell, but the functional programming concepts which make Haskell powerful. The authors have been updating the site with not only the progress, but also taking input from the community as well. Recently, they announced that the writing was complete and the source was handed off to production . Can't wait to get my hands on it, but I've been reading the chapters and following along...
Powered by Community Server (Commercial Edition), by Telligent Systems