Planet F#

From the "Gosh, You Wanted Me to Quote You?" Department...

Thu, 24 Jul 2008 20:03:04 GMT

This comment deserves response:

First of all, if you're quoting my post, blocking out my name, and attacking me behind my back by calling me "our intrepid troll", you could have shown the decency of linking back to my original post. Here it is, for those interested in the real discussion:
http://www.agilesoftwaredevelopment.com/blog/jurgenappelo/professionalism-knowledge-first

Well, frankly, I didn't get your post from your blog, I got it from an email 'zine (as indicated by the comment "This crossed my Inbox..."), and I didn't really think that anybody would have any difficulty tracking down where it came from, at least in terms of the email blast that put it into my Inbox. Coupled with the fact that, quite honestly, I don't generally make a practice of using peoples' names without their permission (and my email to the author asking if I could quote the post with his name attached generated no response), so I blocked out the name. Having said that, I'm pleased to offer full credit as to its source.

Now, let's review some of your remarks:
"COBOL is (at least) twenty years old, so therefore any use of COBOL must clearly be as idiotic."
I never talked about COBOL, or any other programming language. I was talking about old practices that are nowadays considered harmful and seriously damaging. (Like practising waterfall project management, instead of agile project management.) I don't see how programming in COBOL could seriously damage a business. Why do you compare COBOL with lobotomies? I don't understand. I couldn't care less about programming languages. I care about management practices.

Frankly, the distinction isn't very clear in your post, and even more frankly, to draw a distinction here is a bit specious. "I didn't mean we should throw away the good stuff that's twenty years old, only the bad stuff!" doesn't seem much like a defense to me. There are cases where waterfall style development is exactly the right thing to do a more agile approach is exactly the wrong thing to do--the difference, as I'm fond of saying, lies entirely in the context of the problem. Analogously, there are cases where keeping an existing COBOL system up and running is the wrong thing to do, and replacing it with a new system is the right thing to do. It all depends on context, and for that reason, any dogmatic suggestion otherwise is flawed.

"How can a developer honestly claim to know "what it can be good for", without some kind of experience to back it?"
I'm talking about gaining knowledge from the experience of others. If I hear 10 experts advising the same best practice, then I still don't have any experience in that best practice. I only have knowledge about it. That's how you can apply your knowledge without your experience.

Leaving aside the notion that there is no such thing as best practices (another favorite rant of mine), what you're suggesting is that you, the individual, don't necessarily have to have experience in the topic but others have to, before we can put faith into it. That's a very different scenario than saying "We don't need no stinkin' experience", and is still vastly more dangerous than saying, "I have used this, it works." I (and lots of IT shops, I've found) will vastly prefer the latter to the former.

"Knowledge, apparently, isn't enough--experience still matters"
Yes, I never said experience doesn't matter. I only said it has no value when you don't have gained the appropriate knowledge (from other sources) on when to apply it, and when not.

You said it when you offered up the title, "Knowledge, not Experience".

"buried under all the ludicrous hyperbole, he has a point"
Thanks for agreeing with me.

You're welcome! :-) Seriously, I think I understand better what you were trying to say, and it's not the horrendously dangerous comments that I thought you were saying, so I will apologize here and now for believing you to be a wet-behind-the-ears/lets-let-technology-solve-all-our-problems/dangerous-to-the-extreme developer that I've run across far too often, particularly in startups. So, please, will you accept my apology?

"developers, like medical professionals, must ensure they are on top of their game and spend some time investing in themselves and their knowledge portfolio"
Exactly.

Exactly. :-)

"this doesn't mean that everything you learn is immediately applicable, or even appropriate, to the situation at hand"
I never said that. You're putting words into my mouth.
My only claim is that you need to KNOW both new and old practices and understand which ones are good and which ones can be seriously damaging. I simply don't trust people who are bragging about their experience. What if a manager tells me he's got 15 years of experience managing developers? If he's a micro-manager I still don't want him. Because micro-management is considered harmful these days. A manager should KNOW that.

Again, this was precisely the read I picked up out of the post, and my apologies for the misinterpretation. But I stand by the idea that this is one of those posts that could be read in a highly dangerous fashion, and used to promote evil, in the form of "Well, he runs a company, so therefore he must know what he's doing, and therefore having any kind of experience isn't really necessary to use something new, so... see, Mr. CEO boss-of-mine? We're safe! Now get out of my way and let me use Software Factories to build our next-generation mission-critical core-of-the-company software system, even though nobody's ever done it before."

To speak to your example for a second, for example: Frankly, there are situations where a micro-manager is a good thing. Young, inexperienced developers, for example, need more hand-holding and mentoring than older, more senior, more experienced developers do (speaking stereotypically, of course). And, quite honestly, the guy with 15 years managing developers is far more likely to know how to manage developers than the guy who's never managed developers before at all. The former is the safer bet; not a guarantee, certainly, but often the safer bet, and that's sometimes the best we can do in this industry.

"And we definitely shouldn't look at anything older than five years ago and equate it to lobotomies."
I never said that either. Why do you claim that I said this? I don't have a problem with old techniques. The daily standup meeting is a 80-year old best practice. It was already used by pilots in the second world war. How could I be against that? It's fine as it is.

Um... because you used the term "lobotomies" first? And because your title pretty clearly implies the statement, perhaps? (And let's lose the term "best practice" entirely, please? There is no such thing--not even the daily standup.)

It's ok you didn't like my article. Sure it's meant to be provocative, and food for thought. The article got twice as many positive votes than negative votes from DZone readers. So I guess I'm adding value. But by taking the discussion away from its original context (both physically and conceptually), and calling me names, you're not adding any value for anyone.

I took it in exactly the context it was given--a DZone email blast. I can't help it if it was taken out of context, because that's how it was handed to me. What's worse, I can see a development team citing this as an "expert opinion" to their management as a justification to try untested approaches or technologies, or as inspiration to a young developer, who reads "knowledge, not experience", and thinks, "Wow, if I know all the cutting-edge latest stuff, I don't need to have those 10 years of experience to get that job as a senior application architect." If your article was aimed more clearly at the development process side of things, then I would wish it had appeared more clearly in the arena of development processes, and made it more clear that your aim was to suggest that managers (who aren't real big on reading blogs anyway, I've sadly found) should be a bit more pragmatic and open-minded about who they hire.

Look, I understand the desire for a provocative title--for me, the author of "The Vietnam of Computer Science", to cast stones at another author for choosing an eye-catching title is so far beyond hypocrisy as to move into sheer wild-eyed audacity. But I have seen, first-hand, how that article has been used to justify the most incredibly asinine technology decisions, and it moves me now to say "Be careful what you wish for" when choosing titles that meant to be provocative and food for thought. Sure, your piece got more positive votes than negative ones. So too, in their day, did articles on client-server, on CORBA, on Six-Sigma, on the necessity for big up-front design....

Let me put it to you this way. Assume your child or your wife is sick, and as you reach the hospital, the admittance nurse offers you a choice of the two doctors on call. Who do you want more: the doctor who just graduated fresh from medical school and knows all the latest in holistic and unconventional medicine, or the doctor with 30 years' experience and a solid track record of healthy patients?

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

From the "You Must Be Trolling for Hits" Department...

Wed, 23 Jul 2008 20:53:00 GMT

Recently this little gem crossed my Inbox....

Professionalism = Knowledge First, Experience Last
By J----- A-----

Do you trust a doctor with diagnosing your mental problems if the doctor tells you he's got 20 years of experience? Do you still trust that doctor when he picks up his tools, and asks you to prepare for a lobotomy?

Would you still be impressed if the doctor had 20 years of experience in carrying out lobotomies?

I am always skeptic when people tell me they have X years of experience in a certain field or discipline, like "5 years of experience as a .NET developer", "8 years of experience as a project manager" or "12 years of experience as a development manager". It is as if people's professional levels need to be measured in years of practice.

This, of course, is nonsense.

Professionalism is measured by what you are going to do now...

Are you going to use some discredited technique from half a century ago?
•    Are you, as a .NET developer, going to use Response.Write, because you've got 5 years of experience doing exactly that?
•    Are you, as a project manager, going to create Gantt charts, because that's what you've been doing for 8 years?
•    Are you, as a development manager, going to micro-manage your team members, as you did in the 12 years before now?

If so, allow me to illustrate the value of your experience...

(Photo of "Zero" signs)

Here's an example of what it means to be a professional:

There's a concept called Kanban making headlines these days in some parts of the agile community. I honestly and proudly admit that I have no experience at all in applying Kanban. But that's just a minor inconvenience. Because I have attained the knowledge of what it is and what it can be good for. And now there are some planning issues in our organization for which this Kanban-stuff might be the perfect solution. I'm sure we're going to give it a shot, in a controlled setting, with time allocated for a pilot and proper evaluations afterwards. That's the way a professional tries to solve a problem.

Professionals don't match problems with their experiences. They match them with their knowledge.

Sure, experience is useful. But only when you already have the knowledge in place. Experience has no value when there's no knowledge to verify that you are applying the right experience.

Knowledge Comes First, Experience Comes Last

This is my message to anyone who wants to be a professional software developer, a professional project manager, or a professional development manager.

You must gain and apply knowledge first, and experience will help you after that. Professionals need to know about the latest developments and techniques.

They certainly don't bother measuring years of experience.

Are you still practicing lobotomies?

Um....

Wow.

Let's start with the logical fallacy in the first section. Do I trust a doctor with diagnosing my mental problems if he tells me he's got 20 years of experience? Generally, yes, unless I have reasons to doubt this. If the guy picks up a skull-drill and starts looking for a place to start boring into my skull, sure, I'll start to question his judgement.... But what does this have to do with anything? I wouldn't trust the guy if he picked up a chainsaw and started firing it up, either.

Look, I get the analogy: "Doctor has 20 years of experience using outdated skills", har har. Very funny, very memorable, and totally inappropriate metaphor for the situation. To stand here and suggest that developers who aren't using the latest-and-greatest, so-bleeding-edge-even-saying-the-name-cuts-your-skin tools or languages or technologies are somehow practicing lobotomies (which, by the way, are still a recommended practice in certain mental disorder cases, I understand) in order to solve any and all mental-health issues, is a gross mischaracterization--and the worst form of negligence--I've ever heard suggested.

And it comes as no surprise that it's coming from the CIO of a consulting company. (Note to self: here's one more company I don't want anywhere near my clients' IT infrastructure.)

Let's take this analogy to its logical next step, shall we?

COBOL is (at least) twenty years old, so therefore any use of COBOL must clearly be as idiotic as drilling holes in your skull to let the demons out. So any company currently using COBOL has no real option other than to immediately upgrade all of their currently-running COBOL infrastructure (despite the fact that it's tested, works, and cashes most of the US banking industry's checks on a daily basis) with something vastly superior and totally untested (since we don't need experience, just knowlege), like... oh, I dunno.... how about Ruby? Oh, no, wait, that's at least 10 years old. Ditto for Java. And let's not even think about C, Perl, Python....

I know; let's rewrite the entire financial industry's core backbone in Groovy, since it's only, what, 6 years old at this point? I mean, sure, we'll have to do all this over again in just four years, since that's when Groovy will turn 10 and thus obviously begin it's long slide into mediocrity, alongside the "four humors" of medicine and Aristotle's (completely inaccurate) anatomical depictions, but hey, that's progress, right? Forget experience, it has no value compared to the "knowledge" that comes from reading the documentation on a brand-new language, tool, library, or platform....

What I find most appalling is this part right here:

I honestly and proudly admit that I have no experience at all in applying Kanban. But that's just a minor inconvenience. Because I have attained the knowledge of what it is and what it can be good for.

How can a developer honestly claim to know "what it can be good for", without some kind of experience to back it? (Hell, I'll even accept that you have familiarity and experience with something vaguely relating to the thing at hand, if you've got it--after all, experience in Java makes you a pretty damn good C# developer, in my mind, and vice versa.)

And, to make things even more interesting, our intrepid troll, having established the attention-gathering headline, then proceeds to step away from the chasm, by backing away from this "knowledge-not-experience" position in the same paragraph, just one sentence later:

I'm sure we're going to give it a shot, in a controlled setting, with time allocated for a pilot and proper evaluations afterwards.

Ah... In other words, he and his company are going to experiment with this new technique, "in a controlled setting, with time allocated for a pilot and proper evaluations afterwards", in order to gain experience with the technique and see how it works and how it doesn't.

In other words....

.... experience matters.

Knowledge, apparently, isn't enough--experience still matters, and it matters a lot earlier than his "knowledge first, experience last" mantra seems to imply. Otherwise, once you "know" something, why not apply it immediately to your mission-critical core?

At the end of the day, buried under all the ludicrous hyperbole, he has a point: developers, like medical professionals, must ensure they are on top of their game and spend some time investing in themselves and their knowledge portfolio. Jay Zimmerman takes great pains to point this out at every No Fluff Just Stuff show, and he's right: those who spend the time to invest in their own knowledge portfolio, find themselves the last to be fired and the first to be hired. But this doesn't mean that everything you learn is immediately applicable, or even appropriate, to the situation at hand. Just because you learned Groovy last weekend in Austin doesn't mean you have the right--or the responsibility--to immediately start slipping Groovy in to the production servers. Groovy has its share of good things, yes, but it's got its share of negative consequences, too, and you'd better damn well know what they are before you start betting the company's future on it. (No, I will not tell you what those negative consequences are--that's your job, because what if it turns out I'm wrong, or they don't apply to your particular situation?) Every technology, language, library or tool has a positive/negative profile to it, and if you can't point out the pros as well as the cons, then you don't understand the technology and you have no business using it on anything except maybe a prototype that never leaves your local hard disk. Too many projects were built with "flavor-of-the-year" tools and technologies, and a few years later, long after the original "bleeding-edge" developer has gone on to do a new project with a new "bleeding-edge" technology, the IT guys left to admin and upkeep the project are struggling to find ways to keep this thing afloat.

If you're languishing at a company that seems to resist anything and everything new, try this exercise on: go down to the IT guys, and ask them why they resist. Ask them to show you a data flow diagram of how information feeds from one system to another (assuming they even have one). Ask them how many different operating systems they have, how many different languages were used to create the various software programs currently running, what tools they have to know when one of those programs fails, and how many different data formats are currently in use. Then go find the guys currently maintaining and updating and bug-fixing those current programs, and ask to see the code. Figure out how long it would take you to rewrite the whole thing, and keep the company in business while you're at it.

There is a reason "legacy code" exists, and while we shouldn't be afraid to replace it, we shouldn't be cavalier about tossing it out, either.

And we definitely shouldn't look at anything older than five years ago and equate it to lobotomies. COBOL had some good ideas that still echo through the industry today, and Groovy and Scala and Ruby and F# undoubtedly have some buried mines that we will, with benefit of ten years' hindsight, look back at in 2018 and say, "Wow, how dumb were we to think that this was the last language we'd ever have to use!".

That's experience talking.

And the funny thing is, it seems to have served us pretty well. When we don't listen to the guys claiming to know how to use something effectively that they've never actually used before, of course.

Caveat emptor.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

F# subreddit

Tue, 22 Jul 2008 21:18:03 GMT

I created an F# subreddit for F# news/links. I find Reddit’s programming subreddit to be lacking recently, mostly because it seems ALL submissions get downvoted to 0 initially by bots and then only a few articles make it out of the hole. I’m not sure if this is just the current state of the programming [...]

Balanced parenthesis

Tue, 22 Jul 2008 11:48:05 GMT

Checking whether a series of parenthesis is balanced and valid is a classic puzzle in computer science and can be easily met during a job interview. In my opinion, there is no better solution than using a regular expression and solve the problem with a single (but almost unreadable) line of code, however I’d like to [...]

Using LINQ with ArcObjects

Ray Vernagus — Mon, 21 Jul 2008 22:52:00 GMT

Are you using .NET 3.5 to do ArcObjects programming? Are you still manually enumerating through row or feature cursors? Listen up!

It's really very simple to get LINQ running with ArcObjects. All you have to do is add an extension method to either ICursor or IFeatureCursor like so:

public static class ICursorExtensions {

 public static IEnumerable<IRow> AsEnumerable(this ICursor source) {
 Func<IRow> next = () => source.NextRow();
 IRow current = next();
 while (current != null) {
 yield return current;
 current = next();
 } 
 }
}

With your new extension method in hand, you can unleash LINQ on your ArcObjects code. You can now write code like this:

Int32 count = cursor.AsEnumerable().Count();

Or, you could write a query expression against two cursor objects:

var resultSeq =
 from x in cursor1.AsEnumerable()
 from y in cursor2.AsEnumerable()
 where x.get_Value(0) = y.get_Value(0)
 select new { Left = x, Right = y };

You can do a similar thing in F#:

type ICursor with
 member c.AsEnumerable() =
 seq { 
 let next = c.NextRow
 let current = ref (next())
 while !current <> null do
 yield !current
 do current := next()
 }
let count = cursor.AsEnumerable() |> Seq.length

Sure beats manually manipulating an enumerator, doesn't it?

Five Minutes Past Noon Coffee 170

Mon, 21 Jul 2008 08:05:04 GMT

Ben Hall announces IronEditor, a simple dev tool for IronPython and IronRuby. Pretty nice, though fairly simplistic (as Ben readily admits). For example, it doesn't have an interactive mode, only the ability to execute scripts and direct the output to IronEditor's output window. However, it is a good start and I'm sure it'll just get better. One thing he's apparently considering is a Silverlight version. (via Michael Foord)
Speaking of "Iron" tools, Sapphire Steel have had an IronRuby version (in alpha) of their Ruby in Steel product for several months now. I wonder if John's had a chance to play with it.
Speaking of John, the ASP.NET MVC / IronRuby prototype he talked about @ TechEd is now available on ASP.NET MVC Preview 4 via Phil Haack.
Ted Neward has an article exploring the IronPython VS Integration sample that ships in the VS SDK. As I mentioned the other day, we're starting working on a production quality implementation of VS Integration for IPy.
Ophir Kra-Oz (aka Evil Fish) blogs Python for Executives. I like his "Risk, Recruiting, Performance and Maturity" model - four boxes, perfect for keeping an executive's attention! :) Plus Ophir has some nice things to say about IronPython. (via Michael Foord)
Ronnie Maor blogs an extension method for PythonEngine to make Eval simpler. I especially like how he uses string format syntax so you can dynamically generate the code to eval. I wonder what this would look like in IPy 2.0 with DLR Hosting API. (via IronPython URLs)
Speaking of DLR Hosting, Seshadri has another great DLR hosting post, this time hosting IPy inside of VS08 so you can script VS08 events (document saved, window created, etc) with Python.
Justin Etheredge has a bunch of IronRuby posts - Getting IronRuby Up and Running, Running Applications in IronRuby, Learning Ruby via IronRuby and C# Part 1. (via Sam Gentile)
Don Syme links to several F# related posts by Ray Vernagus, though he's apparently also experimenting with IronRuby. I'm really interested in his Purely Functional Data Structures port to F#.
Speaking of F#, Brian has a teaser screenshot of F# upcoming CTP. However, he chooses the New Item dialog to tease, which looks pretty much like the current new item dialog (the new one does have fewer F# templates). However, if you look in the Solution Explorer, you'll notice a real "References" node. No more #I/#R! Yeah!
The interactive graphic in Kevin Kelly's One Machine article is fascinating. It really highlights that the vast vast vast majority of power, storage, CPU cycles and RAM come from personal computers on the edge. Even in bandwidth, where PC's still have the highest share but it looks to be around 1/3rd, the aggregate of all edge devices (PCs, mobile phones, PDAs, etc.) still dominates the data centers.

Sneak peeks into the F# project system, part one

Sun, 20 Jul 2008 22:37:00 GMT

Brian has some snapshots :-)

Sneak peeks into the new F# project system, part one

Sun, 20 Jul 2008 16:02:01 GMT

We're getting closer to the next major release of F#: our first CTP release out of Developer Division. As a result, now is a good time for me to start talking about some of what I've been working on for the past few months: the F# project system. Over the coming weeks I'll describe some of the new-to-F# project system features we'll deliver in the CTP, providing a "sneak peek" at what's coming.

For today, I'll just give an overview of some of the high points, and in subsequent blog entries, I'll dive down into the details of these features. The most noteworthy project system features I can think of are (in no particular order):

New F# project & item templates (for 'New Project' and 'Add New Item')
An 'Add Reference' dialog similar to C#'s, including project-to-project references
Support for linked items ('Add Existing Item'... 'Add as Link')
Support for folders and for reordering files within the project
Project property pages similar to C#'s
F# projects realized as '.fsproj' files that work with MSBuild
Some new features regarding scripts (.fsx files)

Here's a teaser screenshot...

F#: Must fully qualify class members, even inside the class

Ivan — Sun, 20 Jul 2008 11:06:02 GMT

It is not the end of the world, but somewhat annoying: class members must always be referred by their fully qualified name, even inside class methods:

type Foo = class static member Method(x) = ... static member Field = ... member self.FooBar() = Method(42) // won’t work: “constructor Method is not defined” Foo.Method( Field ) // won’t work either end

Boolean operations in F#: spec gone bad

Ivan — Sun, 20 Jul 2008 08:19:02 GMT

The F# language specification does not talk much about Boolean operations, but it does say that ~~~ is op_LogicalNot and &&& is a “bitwise and”, also called land. The && operator is said to be an “address-of” expression.

In reality if ~~~condition does not work: it complains that bool does not define operator ~~~. What works is if not condition.

If if a &&& b does not work either. What works is if a && b. So much for the address-of operator. I am not sure why it is not possible to keep the spec straight and why I should second-guess such simple things…

Awesome new Groovy Mixin Syntax (and F#'s alternative)

Hamlet D'Arcy — Sat, 19 Jul 2008 10:48:00 GMT

Groovy's MetaClass recently acquired some new features...

Check out how easy it is to add multiple new methods to an existing class:

class ListUtils {
 static foo(List list) { "foo called" }
 static bar(List list) { "bar called" }
}
List.metaClass.mixin ListUtils

assert "foo called" == [1, 2, 3].foo()
assert "bar called" == [1, 2, 3].bar()

From the DefaultGroovyMethods source, it looks like you can currently call .mixin on any Class or MetaClass object, passing a new Class (here ListUtils) or list of classes. Awesome.

Paulk made a few comments regarding the Maximum Segment Sum implementation in Groovy from my last post. Looking at both the F# and Groovy original implementations, it was easy to see the value that F# brought for functional programming. But the new versions can be seen here, and the results are not so different.

Open classes are still available in F#, despite it being a statically typed, compiled language. I still find the F# open classes syntax simple and appealing:

open List

type List with
 member x.foo = "foo called"
 member x.bar = "bar called"

if "foo called" <> [1;2;3].foo then failwith "error"
if "bar called" <> [1;2;3].bar then failwith "error"

I especially like how the 'this' reference can be named anything at all (here 'x').

Let the golf begin.

F# and ArcGIS/ArcObjects

Sat, 19 Jul 2008 05:28:00 GMT

Ray Vernagus has posted an introduction to using F# with ArcGIS through ArcObjects.

One of the things I like most about F# is how it allows typed functional programming to be applied to data-rich domains such as Machine Learning, Computer Aided Design (CAD) and Geographical Information Systems (GIS). GIS is of particular interest to me as I learned a lot about this area back in my undergraduate days, and because of the ever-enduring appeal of maps and simulation. Like Kean Wamsley's F# and AutoCAD examples, it's just amazing how easy it is to get going with F# and ArcInfo.

Ray also has a few other useful posts:

Easy Testing in F#

Functional Programming Patterns

Purely Functional Data Structures: an F# Stack

Purely Functional Data Structures: An F# Binary Tree

and a useful update to a code sample in Expert F#:

Kill That Annoying Flicker

Help with study of functional programmers

Fri, 18 Jul 2008 07:38:00 GMT

Are you currently developing or maintaining a medium to large-sized program written in a functional language, such as Haskell, F#, OCaml, or Lisp? Chris Bogart is a PhD student doing a study of functional programmers, as part of a research internship at Microsoft, and would like the opportunity to look over your shoulder while you do debugging or coding on your project. Here's what he says:

I'm looking for people with at least a year's experience doing functional programming, and who are currently working on a real project (i.e. for some purpose other than learning functional programming). I'm only allowed to use people who can work in the US (because of the gratuity, which is taxable income). I'd simply come watch you work, and ask a few questions along the way. You'd do whatever you would normally be doing. If you're near Seattle or Portland, I'd come to your office for a couple of hours. If you're not near Seattle or Portland, then we'd set you up with LiveMeeting or some other remote screencast software so I can watch you from here.

Obviously security concerns are an issue - I will not share any proprietary information that I learn about while visiting you.

In exchange for your help, Microsoft will offer you your pick of free software off its gratuity list (which has about 50 items, including Visual Studio Professional, Word for Mac, XBOX 360 games) or any book from MS Press.

We're doing this because expert functional programmers have not been studied much. We plan to share our findings through academic publications, to help tool developers create debugging tools that are genuinely helpful in real-world settings.

I'm hoping to finish my observations by August 8th, so please contact me immediately if you're interested!

Thank you,

Chris Bogart
425-538-3562
t-chribo@microsoft.com

C# Dictionary to F# Map

Fri, 18 Jul 2008 07:20:04 GMT

Following on from my past blog on effective parallelism I’ve continued digging into the functional language F#. I’m getting there – slowly and I am loving immutability. It’s quite a mindset change from my day-to-day work in imperative languages but I can see a little bit of progress in my functional thinking every day. I’m doing [...]

Groovy vs. F# Showdown - Side by Side Comparison

Hamlet D'Arcy — Thu, 17 Jul 2008 06:58:00 GMT

Ah, our old friend Maximum Segment Sum. Given a list of integers, find the highest sum of any set of adjacent integers. The list [ 1, 2, 3, -4] has an MSS of 6 (1 + 2 + 3). The solution is deceptively simple:

mss = max º sum* º (flatten º tails* º inits)

Briefly explained…

inits() returns all the initial segments of a list in order of increasing length. So the inits of [1, 2, 3] is [ [1], [1,2], [1,2,3] ]

tails() returns all the trailing segments of a list in order of decreasing length. So the tails of [1, 2, 3] is [ [1,2,3], [2,3], [3] ]

Calculating the MSS is as simple as taking the inits of a list, taking the tails of the result, find the sum of each element in that result, and return the maximum entry. Simple, right?

Solving this is a great way to practice functional programming, which I did using Groovy in Function Calisthenics a few months ago, and again last night using F#.

The F# and Groovy results can be seen side by side here: http://www.hamletdarcy.com/files/2008/FsharpVsGroovy.html (I suggest opening it up in a new window big enough so that the lines don’t wrap).

Which begs the question, “Why would you ever want to compare F# (or OCaml) to Groovy?”

Because it explores the answers to a few other questions:

Are dynamically typed languages more concise than statically typed ones? Maybe the comparison between Java and Groovy isn’t a fair comparison, because the results here show F#/OCaml being more concise.

How awful is the F#/OCaml syntax? You can make your own conclusion, but it might be worth spending a few hours with the language before pronouncing a victor. I personally have found the freedom from curly braces and good recursion support a Good Thing.

Do I want to give F#/OCaml a try? That’s kinda the point of writing a post about the language, isn’t it?

So here goes…

Conciseness – The F# version is shorter, there’s no denying that. You also don’t need to add any type information despite the fact that the language is statically typed and the IDE shows you compiler errors as they happen. Also, the F# libraries offer much better support for functional constructs. For instance, the map_concat function doesn’t exist in Groovy, so much of the Groovy code is simply reducing a List of Lists of Lists to a List of Lists. Groovy support for closures and collections is good, but check out the F# documentation and see all functions you wish you had. There is certainly a learning curve to understanding the map*, fold*, and reduce* functions, but I contend that it’s worth the time to learn the fundamentals of Computer Science, which these concepts can rightly be categorized as.

Also, concise List and Map (and Sequence!) creation using the [ a, b, c ] notation is a wonderful thing. But this is an issue with Java, not statically typed languages in general.

The Awful Syntax – Come on, is it really that bad? Sure there is a new set of libraries to learn… but you’re not exactly investing in learning the .NET libraries, just the F# ones. I don’t know a thing about .NET and this was fairly simple. It doesn’t even really rely on the .NET libraries in this example (under the covers it does because it’s implemented in a .NET language and provides interoperability, but that’s another matter). Ricky Clarkson explores having to learn a new syntax in his post “In Defence of (0/:l)(_+_) in Scala”, which includes a quote from David MacIver: "Optimising your notation to not confuse people in the first 10 minutes of seeing it but to hinder readability ever after is a really bad mistake." Exactly. Maybe its time we ditch the C++/Java syntax. It’s not that hard.

Giving F#/OCaml a shot – Let me be clear: Learning F# is not the same as learning .NET. There are plenty of directions online for running it under Mono in Mac/Linux, and the F# install comes with an install-mono.sh shell script. I got it to run on an EEE PC with Xandros Linux without much effort. And there have been plenty of “wow” moments learning F# including wondering how the heck the compiler knows about my types and the satisfaction of finally understanding what “('a -> 'b) -> 'a list -> 'b list” means (Hint: it is a type signature that takes a function and a list and returns another list).

And why would you not want to make this comparison? Groovy is not a functional language and doesn’t advertise itself to be. Closure/lambda support in Groovy is good, and enables a functional style, but it’s not quite a level playing field. A comparison of the languages in an Object Oriented style might well yield different results.

Anyway, give it a shot, my friends, give it a shot. Perhaps the sweet F# handout can shed some light: http://hamletdarcy.blogspot.com/2008/07/f-handout-available.html

Blog change? Ads? What gives?

Wed, 16 Jul 2008 15:29:04 GMT

If you've peeked at my blog site in the last twenty minutes or so, you've probably noticed some churn in the template in the upper-left corner; by now, it's been finalized, and it reads "JOB REFERRALS".

WTHeck? Has Ted finally sold out? Sort of, not really. At least, I don't think so.

Here's the deal: the company behind those ads, Entice Labs, contacted me to see if I was interested in hosting some job ads on my blog, given that I seem to generate a moderate amount of traffic. I figured it was worthwhile to at least talk to them, and the more I did, the more I liked what I heard--the ads are focused specifically at developers of particular types (I chose a criteria string of "Software Developers", subcategorized by "Java, .NET, .NET (Visual Basic), .NET (C#), C++, Flex, Ruby on Rails, C, SQL, JavaScript, HTML" though I'm not sure whether "HTML" will bring in too many web-designer jobs), and visitors to my blog don't have to click through the ads to get to the content, which was important to me. And, besides, given the current economic climate, if I can help somebody find a new job, I'd like to.

Now for the full disclaimer: I will be getting money back from these job ads, though how much, to be honest with you, I'm not sure. I'm really not doing this for the money, so I make this statement now: I will take 50% of whatever I make through this program and donate it to a charitable organization. The other 50% I will use to offset travel and expenses to user groups and/or CodeCamps and/or for-free conferences put on throughout the country. (Email me if you know of one that you're organizing or attending and would like to see me speak at, and I'll tell you if there's any room in the budget left for it. :-) )

Anyway, I figured if the ads got too obnoxious, I could always remove them; it's an experiment of sorts. Tell me what you think.

Enterprise consulting, mentoring or instruction. Java, C++, .NET or XML services. 1-day or multi-day workshops available. Contact me for details.

Kill That Annoying Flicker

Ray Vernagus — Wed, 16 Jul 2008 10:29:00 GMT

The DataSamples sample (pp. 291-303) in Expert F# has an annoying flicker that can be fixed by adding the following line of code after line 101:

do base.SetStyle(ControlStyles.AllPaintingInWmPaint |||
 ControlStyles.UserPaint |||
 ControlStyles.DoubleBuffer,
 true)

If you're writing the code yourself, put the above line after this line:

do base.BackColor <- Color.DarkBlue

Learning Erlang - Erlang Gaining Momentum

Tue, 15 Jul 2008 17:00:00 GMT

You may have noticed that I've been talking a bit about concurrency and Erlang recently. I've started to notice that others are taking notice and giving Erlang another look. I've been a fan of the language for a while, although it is a functional language ala a Haskell, OCaml, F# and so on, it's key strengths doesn't come necessarily from that, but from how it handles concurrency. I'm really fond of the language succinctness and beauty using pattern matching, higher order functions and so on much as I have with F#.

Gaining Momentum

As I stated before, many people are starting to give Erlang another look. For more than 20 years since its inception around 1987, Erlang has received little notice outside of the telecomm industry from whence it came. Then in 1998, it was released as open source, but still not much momentum gathered around the language. But, then things started to change recently. Moore's law started to change, not from faster CPUs, but more cores to the CPUs. Our traditional methods of sequential imperative programming couldn't scale and utilize a lot of the machine this way.

Then we started thinking about locks, monitors, mutexes, but the programming model isn't exactly easy. And to boot, they tend to be a bit low-level for most pieces that we need. Instead, we need more constructs such as guaranteeing pure functions and this function is ok for concurrency at either a language level or at least a library level. Erlang is designed with this in mind, as it is a functional language, so functions are values, and values are immutable. But not only that, the isolation of the processes allows for lightweight processes with no shared state between them. This allows for a given process to fail without taking down the whole system, another important concurrency item that is important.

With this, companies started to take notice. As noted by a post by Chris Vertonghen in his post "Erlang, or Utility-computing vs. Appliance-computing", he notes a few items of interest such as:

Other places are also looking at Erlang. According to the GitHub blog, there is a project called egitd and is a replacement for the stock git-daemon that ships with git. Erlang is perfect for these massively concurrent systems with good failover capabilities.

Getting Started

Getting started in Erlang is pretty easy. Joe Armstrong's Programming in Erlang book tells you all you need to know on how to set it up. I downloaded the distribution from the Erlang site for the runtime and I used Eclipse with Erlide to run through the samples in the book. I had no issues setting it up and it's quite easy to use.

I highly recommend that you get Joe Armstrong's Programming Erlang book as well as check out the Pragmatic Programmer screencasts on Erlang which you can find here.

From the F# Perspective

I've stated before that Erlang-style messaging through mailboxes is already supported in F#. But, it's nowhere near as capable as Erlang. Let's hope these kinds of issues can be raised and added to the libraries. But, let's look at it from another perspective. If you know functional programming and F#, you shouldn't have trouble in Erlang whatsoever. In fact, I have a few examples of functions written in both Erlang and F# that do the same thing.

Pattern Matching

Pattern matching is pretty important in Erlang. Such constructs as for loops do not exist, instead relying on patterns instead to handle the basic control flow. Let's look at a simple area calculator written in Erlang.

-module(geometry)
-export(area/1)
area({rectangle, Width, Ht}) -> Width * Ht;
area({circle, R}) -> 3.14159 * R * R;
area({square, X}) -> X * X.

geometry:area({rectangle, 10, 5}).
geometry:area({circle, 1.4}).
geometry:area({square, 2.5}).

What this sample did was used a tuple to wrap up the type of rectangle, circle and square. Then I create multiple area functions that are my pattern. Then at the bottom, after compiling and exporting my functions through my module, I'm able to call the functions with the given values. How about in F#?

module Geometry =
type Shape = Circle of float | Rectangle of float * float | Square of float

let area = function
    | Circle R -> 3.13159 * R * R
    | Rectangle (Width, Ht) -> Width * Ht
    | Square X -> X * X

Geometry.area (Geometry.Rectangle(10.0, 5.0))
Geometry.area (Geometry.Circle(1.4))
Geometry.area (Geometry.Square(2.5))

I changed the shape to be a discriminated union because overloading of functions to take different tuples is not allowed. Instead, I then switched to a union and pattern matched against that, thus giving the value. Let's move onto more quick examples on how they differ

Lists

Simple list processing is also pretty important. F# and Erlang are also quite similar in this respect as well. There are a few things F# doesn't have such as the remove operator, but for the most part, it's pretty comparable. Functional languages have much different collections than imperative ones, which are optimized for recursion. This includes the feature of the head, the first item in the list, and the tail, the rest of the list. Let's look at a simple sum function in Erlang.

-module(MyLists)
-export(sum/1)
sum([H|T]) -> H + sum(T).
sum([])       -> 0.

L = [1,3,10]
MyLists:sum(L)

What I am able to do is pattern match against the head and the tail of the given list to add the head value to the recursive call to the tail through linear recursion. Next, I'll take that same sample and port it to F# to show how little difference there is.

module MyLists =
let rec sum = function
    | [] -> 0
    | H::T -> H + sum(T)

let l = [1;3;10;]
let lResult = MyLists.sum(l)

Applying lambda expressions on top of lists is pretty simple as well. Here is a simple map function on a list in both Erlang and F#.

-import(lists, [map/2]).
L = [2,4,6,8,10].
LResult = lists.map(fun(x) -> x*x end, L).

And then in F#, to be able to do the map:

[2;4;6;8;10] |> List.map(fun x -> x * x)

As you can see, there are some differences, but for the most part, I haven't had any issues jumping between the languages. This was just meant to be a little exercise about how you can learn from each language. There is much to be learned from both languages, especially in regards to concurrency. I hope to cover more of that shortly.

Wrapping It Up

Functional languages such as Erlang and F# have a lot to offer in terms of concurrency oriented programming. I think now that Moore's law has changed in a way that standard sequential programming doesn't work as well, it's time to start discovering what the functional programming people and for that matter Erlang people have been talking about. This is meant to give you just a little kickstart to look at Erlang, and indeed F# for concurrency. But, not only that, but take the ideas from here and apply them to your other language of choice whether it be C#, Ruby, Python and so on.

The real keys to success for Erlang reside not only in the language itself, but also the frameworks around it, and the tooling, such as the IDEs, etc. Ruby became popular as a language due to the Rails framework although the tooling still isn't the best for it. How will Erlang grow in this area remains to be seen, but I am optimistic.

Recursing into List Processing

Tue, 15 Jul 2008 17:00:00 GMT

Lately I've been getting back to basics with regards to recursion. This is a basic and essential skill, especially in the functional programming world. Today's dive will be into immutable lists and recursion. I'll do my best to provide the F# and C# equivalent to each call. This is in part of the back to basics and from here I'll move onto other subjects.

Let's catch up to where we are today:

Recursive List Processing

In the functional programming world, and especially in the functional programming world are singly linked immutable lists. Each of the items in the list is a cell with a reference to the next item in the list. For functional programming, unlike imperative programming, they are optimized for recursion. By that I mean that they have a head (the first item) and the tail (the rest of the list). F# has the use of this through the List<'a> class.

Let's walk through a simple example of how you might sum up all items in a list using recursion as well as one for calcuating the length of the list. In F# this is pretty simple, using pattern matching.

F#

#light module ListExtensions = let rec sum = function | [] -> 0 | h::t -> h + sum t let rec length = function | [] -> 0 | h::t -> 1 + length t [1..20] |> ListExtensions.sum |> print_any
[1..10] |> ListExtensions.length |> print_any

This function above had a simple pattern matching over the list which said for an empty list, the result would be zero, else it would be the sum of the head and the calculation of the rest of the list and eventually winds its way down to the end of the list. Likewise inthe length, it adds 1 to the calculation of the length function until it winds down to nothing left in the list. In the base .NET libraries, we don't have a list like this, but it's actually not that hard to create one. Let's walk through a simple immutable linked list much like the List<'a> in F#.

Let's define in C# what something like that might look like. I'll start with something the way Wes Dyer had it but with a few changes:

public interface IImmutableList<T> : IEnumerable<T>
{
    T Head { get; }
    IImmutableList<T> Tail { get; }
    bool IsEmpty { get; }
    bool IsCons { get; }
}

As you can see, we have a head, a tail and a way to determine if this list is empty or if it is a cons. All very important pieces to the puzzle. This also inherits the IEnumerable<T> interface as well so that we can iterate this should we need to. Now, let's go into the implementation details of the immutable list.

public class ImmutableList<T> : IImmutableList<T>
{
    public class EmptyList : ImmutableList<T> { }

    public class ConsList : ImmutableList<T>
    {
        internal ConsList(T head, IEnumerator<T> enumerator)
        {
            Head = head;
            this.enumerator = enumerator;
        }
    }

    private static readonly IImmutableList<T> empty = new EmptyList();

    IImmutableList<T> tail;
    IEnumerator<T> enumerator;

    public T Head { get; private set; }

    public static IImmutableList<T> Cons(T head, IImmutableList<T> tail)
    {
        return new ConsList(head, tail.GetEnumerator());
    }

    public static IImmutableList<T> Cons(IEnumerator<T> enumerator)
    {
        return enumerator.MoveNext() ? new ConsList(enumerator.Current, enumerator) : empty;
    }

    public IImmutableList<T> Tail
    {
        get
        {
            if (enumerator != null)
            {
                tail = Cons(enumerator);
                enumerator = null;
            }
            return tail;
        }
    }

    public bool IsCons { get { return this is ConsList; } }

    public bool IsEmpty { get { return this is EmptyList; } }

    public static IImmutableList<T> Empty { get { return empty; } }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return ((IEnumerable<T>) this).GetEnumerator();
    }

    public IEnumerator<T> GetEnumerator()
    {
        for (IImmutableList<T> current = this; !current.IsEmpty; current = current.Tail)
            yield return current.Head;
    }
}

Now what I have done here is implemented two internal lists to represent a "cons" and one to represent an empty list. This helps when determining whether the list is empty or not without having to check references and whether something is null. Inside my ConsList<T>, I'm able to create a new instance of the ImmutableList<T> with the head value and the rest of the list.

The head of the list is just simply that, the first item. When the tail property is called, I create a new IImmutableList<T> with my enumerator by calling the Cons method. I also have properties which define and empty list, whether it is empty or whether it is a "cons". Like I said, there's nothing hard about this.

Then I'm able to define a Sum and Length methods much as above with something like this:

public static int Sum(this IImmutableList<int> list)
{
    if (list.IsEmpty)
        return 0;

    return list.Head + Sum(list.Tail);
}

public static int Length<T>(this IImmutableList<T> list)
{
    if (list.IsEmpty)
        return 0;

    return 1 + Length(list.Tail);
}

And then invoking this is pretty straight forward through the main method:

static void Main(string[] args)
{
    var enumerator = Enumerable.Range(1, 10).GetEnumerator();
    var list = ImmutableList<int>.Cons(enumerator);
    var sum = list.Sum();
    var length = list.Length();
    Console.WriteLine("List sum : {0}", sum);
    Console.WriteLine("List length :{0}", length);
}

But what about tail recursion when doing list processing? Let's walk through one more example of tail recursion with lists. In this example, I'm going to go ahead and return the last item in the list. It's a pretty simple and straight forward function which determines whether the list only has a head, or if it also has a tail, then recurse on the function again.

F#

#light

module ListExtensions =
let rec last = function
    | [] -> invalid_arg "last"
    | [h] -> h
    | h::t -> last t

[1;5;3;2;6;] |> ListExtensions.last |> print_any

Now the C# version should look just as familiar to you. Basically instead of the pattern matching, which I'd love to have in C#, I'm using if statements to determine whether I'm returning the head, or the evaluation of the Last function again until I wind down to the head.

C#

public static T Last<T>(this ImmutableList<T> items)
{
    if(items.IsEmpty)
        throw new ArgumentNullException("items");

    var tail = items.Tail;
    return tail.IsEmpty ? items.Head : tail.Last();
}

var e1 = new List<int> {1,5,3,2,6}.GetEnumerator();
var items = ImmutableList<int>.Cons(e1);
var last = items.Last();
Console.WriteLine("Last item: {0}", last);

In the past I covered why tail recursion is important in my previous post. Unfortunately, the C# code won't do much for you uniless the compiler is optimized for tail calls, or you are using the x64 version of Windows. I have some of these samples in my Functional C# samples on MSDN Code Gallery.

Wrapping it Up

As you can see, recursion is a pretty interesting topic. One of the best ways to avoid mutable state in your programs is through recursion. I've shown some simple examples of where recursion can help to solve some of those issues. This will wrap up a lot of the discussions about recursion and then I'm moving into such topics as memoization, continuations and so on. The code samples will be available on the Functional C# Samples during this back to basics trip.

VSLab R. Daneel released

cisterni.nospam@nospam.di.unipi.it (cisterni) — Tue, 15 Jul 2008 11:45:00 GMT

I just released the new release of VSLab codenamed R. Daneel. This release adds the package feature, an important element to build DSL and tools on top of VSLab. Packages are simply .NET assemblies with appropriate metadata used by VSLab to offer a dialog to manage them. Ok, ok you can code it, but it's handy to select which packages should be loaded, if at startup, and if you are lazy enough you can even ask for automatic namespace opening!

This is how package manager looks like:

You can load packages interactively or flag them for startup. You have two assembly caches (different from the GAC so you are not required to understand strong naming) for packages, one in the VSLab installation dir, and the other in the user profile. I managed to start the UAC dialog on Vista to have packages installed under program files.

Help with study of functional programmers

Tue, 15 Jul 2008 07:40:04 GMT

Are you currently developing or maintaining a medium to large-sized
program written in a functional language, such as Haskell, F#, OCaml,
or Lisp? I'm a PhD student doing a study of functional programmers, as part of
a research internship at Microsoft, and I would like the opportunity to look over
your shoulder while you do debugging or coding on your project.

I'm looking for people with at least a year's experience doing
functional programming, and who are currently working on a real
project (i.e. for some purpose other than learning functional
programming). I'd simply come
watch you work, and ask a few questions along the way. You'd do
whatever you would normally be doing. If you're near Seattle or
Portland, I'd come to your office for a couple of hours. If you're
not near Seattle or Portland, then we'd set you up with LiveMeeting
or some other remote screencast software so I can watch you from here.

Obviously security concerns are an issue - I will not share any
proprietary information that I learn about while visiting you.

In exchange for your help, Microsoft will offer you your pick of free
software off its gratuity list (which has about 50 items, including
Visual Studio Professional, Word for Mac, XBOX 360 games) or any book
from MS Press.

We're doing this because expert functional programmers have not been
studied much. We plan to share our findings through academic
publications, to help tool developers create debugging tools that are
genuinely helpful in real-world settings.

I'm hoping to finish my observations by August 8th, so please contact
me immediately if you're interested!

Thank you,

Chris Bogart
425-538-3562
t-chribo@microsoft.com

(Correction 7/18/08: I was mistaken in my original posting: I *can* use
participants in Europe as well as the US)

ICFP 2008 Programming Contest

Mon, 14 Jul 2008 09:45:01 GMT

This year, for the first time, I participated in the ICFP programming contest. This year's contest involved commanding a rover to navigate the Martian terrain: see the contest task description. It was tons of fun; I teamed up with Chris Smith, Luke Hoban, and Dustin Campbell for an F# team.

In the end we submitted an entry that does pretty well on a variety of maps. Some features of our entry:

It is a heuristics-based approach. We have some general computations from what we learned about the world physics, but there are lots of hacks where we have arbitrary parameters like "multiply by 2.2" for no other reason than that seems to work well. And there are tons of if-then-else cases for various edge cases (e.g. if we think we are going too fast, then turn less sharply, unless about to crash, ...).
It is completely "local" - we use the current state for each movement, and do not plan for the long term. In general we either 'aim home' or else 'aim tangent to the next closest item blocking our path'.
We use a 'connected components' model to group together overlapping (or nearly-overlapping) obstacles. That way, we can steer around an entire group of nearby objects rather than trying to precisely weave between them. (I lifted code directly from this post, hurray!) Our components are connected on an 'absolute' scale; it may have been better to group on a relative scale (the farther two distant objects are from you, the more likely it's an advantage to treat them as a single connected component despite any absolute distance between the two distant objects), but I only just thought of that now. I think we 'connect' any two craters that have only a two-rover-diameter-or-less distance between their perimeters. This avoids slowing down for precise steering through narrow gaps, but might also cause us to drive long distances around objects we could in fact squeeze through.
We only rarely slow down - if we are pointed away from home base, or if soon-after-the-next-tangent-we-are-currently-aiming-for we see an object coming soon right behind it. (Our heuristics for computing 'stopping distance' and 'how fast we can brake to avoid things' are decent, but not outstanding.)
We almost completely ignore Martians (very little logic to account for them). This is risky, but there is no good alternative.
We ignore many contest parameters, such the 'max lookahead' of our sensors. As a result, if we are given a fast rover who cannot see very far ahead, he will drive way too fast directly ahead into the unknown.
We are very good at turning quickly and smoothly, despite using a very ad-hoc heuristic approach that's only loosely based on the (supposed) physics of the task specification.
We did not create enough of our own sample maps, so I expect there are important cases we neglected.
There are lots of features we considered implementing but did not have time. For example, if we are trapped inside a connected component of obstacles with no line of sight out (imagine being inside the top-right of an @-shaped maze), I think we will get befuddled. We have 'tunnel vision', and may potentially drift gently into a boulder that is just barely to the side of the direction we are headed. We never consider using bouncing off boulders to our advantage. We thought a lot about a completely different approach that would just predict and simulate the future, and then search futures for best possible outcomes with very little heuristic strategy and mostly learning-on-the-fly, but did not have time/resources to try it.
We had lots of good, colorful debugging output.

Of course we used our in-house latest-and-greatest F# bits, which are very useful. I haven't written any blogs in the past month, partly because I've been so busy adding features and fixing bugs for our upcoming CTP release of F#. I am looking forward to showing off all the hard work we've been doing on F#!

1.9.4.19 release

Mon, 14 Jul 2008 08:42:00 GMT

We've posted a minor update to version 1.9.4 (called 1.9.4.19). The change notice is in the README and below. There are three fixes/changes in this release

Ã There was a glitch that prevented F# version 1.9.4.17 programs working well on Mono. A workarounds was mentioned here http://laurent.le-brun.eu/site/index.php/2008/06/05/36-how-to-use-fsharp-1-9-4-17-on-mono, though this workaround should now no longer be needed.

Ã WebRequest.GetResponseAsync has been removed from FSharp.Core.dll, to help allow F# programs to be used on SIlverlight and other platforms where this method either doesnât exist or is in a non-standard place. See the release notes if you need this method (for example, it is needed for some examples in Expert F#)

Ã We have fixed a compiler problem related to .NET 3.5 SP1 Beta (âstrange entry in exported types tableâ)

http://research.microsoft.com/research/downloads/Details/7ac148a7-149b-4056-aa06-1e6754efd36f/Details.aspx (MSI)

http://research.microsoft.com/research/downloads/Details/6f48a466-4294-4973-9e15-25e0ddff422f/Details.aspx (ZIP)

Thanks

Don

F# On Mono

The Mono 2.0 profile for F# is now used. On Mono the F# compiler is now invoked using mono bin\fscp.exe. See the notes above for details of this. NOTE: compiler startup times may be reduced on Mono because the Mono 1.9 doesn't support 'Ahead of Time Compilation' for its 2.0 profile. This won't normally be a problem if you're only using F# Interactive (fsi.exe). If it is a problem then see the instructions above for using the .NET 1.x profile compiler.

Library

WebRequest.GetResponseAsync now removed from the F# library since its use of a System.Net method makes FSharp.Core.dll unusable on some .NET platforms. To use this method use:

type System.Net.WebRequest with

member x.GetResponseAsync() =

Async.BuildPrimitive(x.BeginGetResponse, x.EndGetResponse)

Bugs fixed

2033 F# Compiler doesn't work with type forwarders found in .NET Framework 3.5 SP 1 Beta1

Morning Coffee 167

Mon, 14 Jul 2008 05:30:01 GMT

If you're a gamer, you're probably already well aware that E3 is this week. The Too Human demo has already been released. I have a friend who's been working on "something" that will be announced today (I think).
Live Mesh folks pushed out an update Friday. Among the new features is the ability to sync folders among peers but NOT up to the cloud. This is cool because it means I can sync my many many GB of pictures and music on my home machine backed up with Carbonite. This means I can sync them without blowing thru my 5GB Mesh storage limit.
It looks like there's a new F# drop - 1.9.4.19 - ~~but as usual there is no announcement or details as to what's new. Release notes guys, look into it.~~ UPDATE - Don Syme blogged the release, and it's pretty minor. a .NET FX 3.5 SP1 bug fix, a fix for Mono, and they removed WebRequest.GetResponseAsync to make F# work on Silverlight. And the release notes are in the readme. My bad.
Speaking of F#, it was "partially inspired" by OCaml, so when I see papers related to OCaml, I immediately wonder if I an apply the described techniques to F#. "Catch me if you can, Towards type-safe, hierarchical, lightweight, polymorphic and efﬁcient error management in OCaml" is one such paper. (via LtU)
Speaking of functional programming, Matthew Podwysocki posted a bunch of FP links as well as a Code Gallery Sample on FP in C#. Good stuff.
As per Scott Guthrie, it looks like there's a new ASP.NET MVC drop coming this week.
Based on posts by Ted Neward, Dare Obasanjo and Steve Vinoski, Google Protocol Buffers sounds like it's going to be a dud. Note, I haven't looked at it depth personally, I'm just passing on opinions of some folks I read and trust.
Speaking of Dare, both he and James Hamilton take a look at Cassandra and come away impressed. I wonder how easy it is to code against from Python and/or .NET?
Bart de Smet has a cool sample of calling out to PowerShell from IronRuby via the backtick command. Pretty cool, but it would even cooler to show how to call out to PS and return .NET objects to Ruby (though that would probably not be spec compliant for the backtick command).
Here's a MS code name I had never heard before - Zermatt. It's "a framework for implementing claims-based identity in your applications." (via Steve Gilham)

F# 1.9.4.19 runs out of the box with Mono in Linux

Sun, 13 Jul 2008 17:00:00 GMT

Don Syme just announced a minor update to the F# environment, minor may be but of great interest to a certain community: it so happens that at some point F# stopped working properly in Linux, a workaround was published (and it actually works, but you've got to follow the instructions carefully). Well, not anymore, 1.9.4.19 works out of the box with Mono in Linux, you just have to download it, unzip it, and then happily type "mono fsi.exe":

So now I've got one less pretext for not writing that book "Learning to program the functional way in an open source environment using a cool Microsoft technology" that will make me famous...

Under the hood

cisterni.nospam@nospam.di.unipi.it (cisterni) — Sun, 13 Jul 2008 06:14:00 GMT

I'm going crazy in refactoring and improving VSLab runtime. I'm trying to improve early design choices made while trying to find the right approach to implement it. This is important because the new package mechanism requires better design. I'm changing also core names and I've added a new VS command to be used to move as much code as possible into fsi.exe instead than into the VS addin. The FSIExec command allows F# functions to send a string to the F# interactive top-level for evaluation. This is a powerful form of meta-programming allowing F# code generating code fragments to be evaluated in the fashion of the eval function of dynamic languages.

The Countdown Puzzle

Mike — Sat, 12 Jul 2008 23:27:00 GMT

Thank you for the comments. Brian has posted an optimisation to that function combine that lets this solution run quick enough to win on TV. Sigma has pointed out that there are bits missing from the code because of the way I have pasted into the editor. And I have realised that I did not need to create a cons function to do that section, I can create an anonymous function with fun just where I need it. So here is the final version:-


#light
 
type Op = | Add | Sub | Mul | Div
 
type Expr = Val of int | App of Op * Expr * Expr
 
let valid op x y =
 match (op, x, y) with
 | (Add, _, _) -> x < y
 | (Sub, x, y) -> x > y
 | (Mul, _, _) -> (x > 1) && (y > 1) && (x < y)
 | (Div, x, y) -> (y > 1) && (x % y = 0)
 
let apply op x y =
 match (op, x, y) with
 | (Add, x, y) -> x + y
 | (Sub, x, y) -> x - y
 | (Mul, x, y) -> x * y
 | (Div, x, y) -> x % y
 
let rec eval e =
 match e with
 | Val n -> if n > 0 then [n] else []
 | App (op, e1, e2) -> [for x1 in eval e1 
 for x2 in eval e2 
 when valid op x1 x2 -> apply op x1 x2]
 
let rec subs lst = 
 match lst with
 | [] -> [[]]
 | x::xs -> let yss = subs xs in
 yss @ (List.map (fun lst -> x::lst) yss)
 
let rec interleave x xs =
 match xs with
 | [] -> [[x]]
 | y::ys -> (x::y::ys) :: List.map (cons y) (interleave x ys)
 
let rec perms lst =
 match lst with
 | [] -> [[]]
 | x::xs -> List.concat (List.map (interleave x) (perms xs))
 
let choices lst = List.concat (List.map perms (subs lst))
 
let rec split lst =
 match lst with
 | [] -> []
 | [_] -> []
 | x::xs -> ([x],xs)::[for (ls,rs) in split xs -> (x::ls,rs)]
 
let ops = [Add; Sub; Mul; Div]
 
let combine left right = 
 [for o in ops 
 let x = App (o, left, right)
 let e = (eval x)
 when not e.IsEmpty -> App (o, left, right)]
 
let rec exprs lst =
 match lst with
 | [] -> []
 | [n] -> [Val n]
 | ns -> [for (ls,rs) in split ns
 for l in exprs ls
 for r in exprs rs
 for e in combine l r -> e]
 
let op_to_str op =
 match op with
 | Add -> "+"
 | Sub -> "-"
 | Mul -> "x"
 | Div -> "/"
 
let rec to_str expr =
 match expr with
 | Val n -> n.ToString()
 | App (op, e1, e2) -> "(" + (to_str e1) + (op_to_str op) + (to_str e2) + ")"
 
let solutions ns n = [for nns in choices ns
 for e in exprs nns
 when eval e = [n] -> e]
 
let print_solutions ns n = List.map to_str (solutions ns n)

F# Compiler

Fri, 11 Jul 2008 05:14:01 GMT

F# is a variant of the ML programming language for .NET and has a core language similar to OCaml. F# is a mixed functional/imperative/object-oriented programming language excellent for medium/advanced programmers and for teaching. It also can be used to access hundreds of .NET libraries, and the F# code can be accessed from C# and other .NET languages. This release of F# includes a command-line compiler; “F# for Visual Studio,” which provides interactive syntax highlighting, parsing, type checki...

F# Compiler (zip)

Fri, 11 Jul 2008 05:13:04 GMT

Available via zip distribution rather than msi. F# is a variant of the ML programming language for .NET and has a core language that is similar to OCaml. F# is a mixed functional/imperative/object-oriented programming language excellent for medium/advanced programmers and for teaching. It also can be used to access hundreds of .NET libraries, and the F# code can be accessed from C# and other .NET languages. This release of F# includes a command-line compiler; “F# for Visual Studio,” which pro...