Since the publication of the F# article in the MSDN Launch magazine, I've gotten some feedback from readers (for which I heartily thank you all, by the way), but in particular I've gotten two emails from "tms" that I thought deserved more widespread notice and commentary.

I'm happy to give full credit to "tms" for his comments, but thus far I haven't heard back from him saying it was OK to do so; that said, his points are valid, and I think important for the rest of the world to hear, so I'm posting this under a pseudonym until he gives permission to offer up his real name.

In his first note, tms says....

I appreciated the (F#) article. I would like to point out one error.

You wrote:

Like many functional languages, F# permits currying ...

let add5 a =
    add a 5

Your example does not demonstrate currying well, as it could be written in any non-currying language such as C#. (It is indeed an "idiom" that one uses in C# to manually do the equivalent of currying, where desired.)

Here are two statements, either of which would demonstrate currying:

   1: let add5 = add 5

   2:  

   3: 5 |> (add 5)

Neither of these two statements have any direct equivalent in C#, because C# lacks the concept of currying.
What is significant about these statements, is "add 5" -- the use of add with only one of its two parameters. This is the essence of currying. It takes a function that requires n parameters, and directly turns it into a function that requires n-1 parameters, with no need to name or otherwise talk about the "missing" parameter.

Agreed, but even there, it's possible to do in C# with the use of (multiples of) anonymous methods. For example, the "add5" example you use can be seen as something akin to this:

   1: // Note this has not been compiled with anything except the

   2: // Neward & Associates Blog Compiler (i.e., my eyes)

   3: public class Container

   4: {

   5:     public void add(int a, int b) { return a + b; }

   6:  

   7:     // This is the simple, hard-coded version

   8:     public void add5(int b) { return add(5, b); }

   9:  

  10:     // This is the more complex approach that arguably is closer to F#

  11:     public delegate int AddMethod(int, int);

  12:     public AddMethod Add = new AddMethod(add);

  13:  

  14:     public delegate int Add5Method(int);

  15:     public AddMethod Add5 = new Add5Method((b)=> return Add(5, b));

  16: }

Your second example, using the pipeline operator can, in fact, also be done using C# and a well-established set of delegate types arranged into a pipeline, a la how PowerShell passes objects (or lists of objects) from one Cmdlet to another....

... but your point is still well taken; there's much better examples of currying in the world; Don Syme (who tech-reviewed the article) openly questioned whether or not currying was a good thing to bring up in this introduction, and I argued that I thought it was necessary to at least open the subject in order to explain some of the inherent power of functional programming (and, by extension, some of the motivation for learning F#).

Net result: there is some smoothing of the story on F# yet to be done. You only find this out from presenting a story to an audience, hearing their feedback, and iterating on it further.

In his second note, tms points out

Your evolution of

let results = [ for i in 0 .. 100 -> (i, i*i) ]

into:

let compute2 x = (x, x*x)
let compute3 x = (x, x*x, x*x*x)
let results2 = [ for i in 0 .. 100 -> compute2 i ]
let results3 = [ for i in 0 .. 100 -> compute3 i ]

I think this could use a better explanation about what is being shown.

When I first read it, my reaction was:

'I can do the same thing in C# -- you just replaced an an expression in the language, "(i, i*i)" with a function that returns the value of that expression, "compute2 i".'

It wasn't until I sat down to write the C# equivalent that I saw what the benefit is: in F# it is easy to define functions anywhere. In C#, the code would have occurred somewhere in a method of some class, so if "compute2" were a static method on the same class, it would be just as easy to use -- it would simply be "compute2(i)". But in C# I can't embed it as is done in F#. Somewhere else in the class I have to add the function:

   1: // This is C#

   2: class MyClass {

   3:  

   4:   method SomeMethod() {

   5:     ...

   6:     result.Push( Pair(i, i*i) )

   7:     ...

   8:   }

== can be turned into ==>

   1: class MyClass {

   2:   ...

   3:   static method compute2 (int a) { return Pair(i, i*i); }

   4:   ...

   5:  

   6:   method SomeMethod() {

   7:     ...

   8:     result.Push( compute2(i) )

   9:     ...

  10:   }

  11: }

  12:  

It would be really cool if C# let you define a function locally, something like:

   1: class MyClass {

   2:  

   3:   method SomeMethod() {

   4:     ...

   5:     function compute2 (int a) { return Pair(i, i*i); }

   6:     result.Push( compute2(i) )

   7:     ...

   8:   }

   9: }

  10:  

Is that the benefit you were describing?

Weeeelll..... I'd like to say that was the case, but in truth, I don't think I had that in mind when I was writing the article. In fact, it's a bit hard, looking back, exactly what I had in mind during that particular section of the article, except perhaps to try and explain a bit more of the F# syntax. I think what I was trying to do was show how functions could be used in a higher-order manner, but with a simple (arguably trivial) manner, which, in retrospect, doesn't really do the concept of higher-order functions much justice. I'd like to use as my excuse the technical writer's traditional escape, which is to say, "Hey, you try explaining a complex concept in 5000 words, along with introducing basic syntax and still make it relevant to the audience", but in truth, that's just an excuse, and I admit it. *sigh* Fortunately, folks like you are around to point out the flaws in my prose, and (hopefully) make it stronger the next time around.

The other thing to remember, too, that as with most language comparisons, it isn't so much a matter of what I can or can't do in a particular language vis-a-vis a different language (F# vis-a-vis C#, in this case), but more a question of "What does this language allow me to express as a first-class concept that the other one forces me to express via much lower-level constructs?" Just about everything that F# offers can be replicated in C#--thanks in no small part to anonymous methods/lambdas, to be frank--but forces the C# developer into writing much of the scaffolding that has to be in place. (If you think about it, this has to be true, at least at some level, because both F# and C# run on top of the CLR, which means they each have to 'boil down' to CIL at some level, and given the relatively high level of fidelity between C# and CIL, almost any construct expressed in CIL can be 'redrawn' in C#, if we're willing to.)

Case in point: consider the snippet tms calls out above:

let compute2 x = (x, x*x)
let compute3 x = (x, x*x, x*x*x)
let results2 = [ for i in 0 .. 100 -> compute2 i ]
let results3 = [ for i in 0 .. 100 -> compute3 i ]

If we take this snippet and run it through the F# compiler grinder, then look at the results in ILDasm, we get an interesting comparison of how F#'s first-class support for functions maps into C#'s view of the world.

First, ILDasm:

(You'll note I spared you the huge text dump of "ildasm /out:example.il example.exe", since that would have more noise than signal. Feel free to perform the experiment on your own, if you'd like to see the raw output.)

As you can see here, the F# "top-level" code gets stored into a static method _main stored in the class "<StartupCode$example>" in the namespace "<StartupCode$example>", and yes, _main() is marked with the CIL ".entrypoint" directive, telling the CLR that this is where life begins for this particular assembly. Notice as well how the filename becomes the class "container" for the functions defined therein (the class "Example"), and the functions in particular--compute2() and compute3()--are exported as public static methods. You can see, however, that their parameter types are definitely more complex than the form we would use in traditional idiomatic C#, tuples instead of a list of individual parameters, which tms tries to keep fidelity to in his pseudo-C# translation. The "results2" and "results3" identifiers are in turn kept as properties, exposed on the Example class, and to top it off, are actually defined (not once, but twice) as nested classes of the Example class, because these are, in fact, lists of results, not a single result.

I could go on, but frankly, the noise would begin to swamp the signal. I leave the exercise of opening example.exe in Reflector up to the interested reader. (If you're even remotely interested in F#, I highly recommend doing so once or twice, just to get an idea of how much scaffolding and infrastructure F# is putting into place for you. It's also incredibly useful for when you're trying to figure out C#-calling-F# interop issues.) It's particularly interesting to walk the path of how results2 gets generated, and how wildly different that is from the traditional C# "for" loop. It turns out that everything I'm doing in the code snippet above can be done in C#, but wow, why would you want to? Particularly if you want to get exactly the same kind of fidelity to side effects (that is to say, none at all) that the F# approach gives you?

Both are excellent points, tms, and thanks for taking the time to offer feedback.

So I took the plunge and installed Leopard onto my MacBook Pro tonight, and as of right now, I'm not a happy camper.

The installation started off well enough--pop in the DVD, bring up the installer, double-click, answer a few form fields, then wait as it verifies the DVD, reboots into the CD-launched installer again, answer a few form fields, then sit and read my latest copy of Ellery Queen Mystery Magazine while the installation completes. Roughly an hour or so later, it's done, and I have a bright and shiny new Leopard installation on my Mac. Yay.

Software Update tells me there are a few things that need updating--sure, that makes sense, since I think the latest version of Leopard is actually now 10.5.2, so go ahead.

Bad move.

Ever since that update, any attempt to join my home wireless network fails miserably. AirPort can clearly see the network--it discovers the SSID without a problem--but joining it yields no love. The error that shows up in the console log is always this pair:

airportd Error: Apple80211Associated() failed -6

_emUIServer Error: airport MIG failed = -6 ((null) port = 60027)

I've tried several things suggested in the Apple forums, from changing the order of connected systems to put the Airport on the top, to clearing out my list of remembered SSIDs, to turning the AirPort off and back on again, to downloading the TimeMachine upgrade and installing it, even to blowing out the PRAM on boot. Nothing doing.

Tomorrow we make a trip to the Apple Genius Bar to see what those geniuses have to say, but I'm not optimistic. I will update this blog and apologize profusely if I'm wrong, of course, but given the number of unsuccessful support calls that people are lamenting, I'm guessing this will be one of those "Well, if you want to ship it back to the factory, sir, ...." responses, which is NOT an option.

Well... OK, it is an option, given that I do most everything in VMWare images, sure, but the thought of going back to my T42p (with only 1.5GB of RAM on it, compared to the full 4GB on my MBP) is not endearing to me, particularly because Vista has a problem with releasing the USB hard drives that I store most of the VMWare images on....

Somebody please tell me they have an easy fix for this, one which Googling has not yet revealed....

Update: So I took my MBP into the Apple Store... and, naturally, the wireless on the MBP picks up the Apple Store's network just fine. Grrr. Regardless, I had them do an "archive and install" of 10.5.1 onto the machine, and when I got home... perfect! Sees and connects to my home wireless without a hitch. So I'd suggest for those who recently moved up to 10.5.2, try dropping back to 10.5.1 and see if that solves the problem.

Meanwhile, I'll be holding off of doing the 10.5.2 update for a while, I think. Of course, that also means I can't do the iPhone SDK, I think, so I may try the update once more just to see if it'll take this time, and if it doesn't, then off to the Apple Store again for the 10.5.1 re-install again. But at least this time, I'd know what the viable solution is. (I hope....)

Not the BitTorrent of some particular movie or game, but the torrent of changes to the JDK that were held up pending a final blessing on the OpenJDK Mercurial transition. How do I, a non-Sun employee know this? Because I'm subscribed to the build-dev mailing list (which seems to be getting the Mercurial changeset notification emails), and on Wednesday (March 26th), one such email contained 72 new changesets, ranging from extensions to the query API for JMX 2.0:

6602310: Extensions to Query API for JMX 2.0

6604768: IN queries require their arguments to be constants

Summary: New JMX query language and support for dotted attributes in queries.

to bug fixes in javaw.exe for the Windows JRE:

6596475: (launcher) javaw should call InitCommonControls

Summary: javaw does not show error window after manifest changes.

to some changes to the Process class to better allow for IO redirection:

4960438: (process) Need IO redirection API for subprocesses

and more beyond that.

I have to say, I'm getting a little giddy watching all these things flow into the JDK--it's been a while since I just sat and watched the build notification messages on a large project like this, and it always gives me this weird sense of accomplishment, even though it's not work that I'm doing or arguably even care about. But it should stand as a clear sign to anybody who think Java-the-platform is "done"--the guys at Sun certainly don't think so, and more importantly, are putting in the effort to improve it.

Except now, we can see the work being done, which makes all the difference in the world.

Some of you may remember that on several speaker panels I was on, I was a bit bullish (on the surface of things) about the OpenJDK process. I think my exact comments were, "I think for the majority of Java developers, this is a 'No Big Deal, Move Along, Nothing to See Here' kind of step." I still believe that, in fact: I believe that to the vast majority of Java developers, the fact that anybody can now see the sausage being made yields no real advantage, and therefore is of no real interest.

But to the handful of Java developers who refuse to see the JVM or the Java libraries (or even the Java compiler) as a black box, this is huge. We can now not only post the bugs that we run across during development, and more importantly, subscribe to the mailing lists, watch for the bug fix notification, apply the Mercurial changeset that patches the bug, and if the patch doesn't work, notify Sun. But if the patch does work, not only can we confirm the bug's elimination, but we can move beyond it, even before the production release of the next Java build. It may not be something you do on a regular basis, but when you're completely blocked waiting for a bug fix from Sun...

... that's huge.

Quick note before I head off to the conference center to do the Scala talk: Darryl Taft covers the "Why the Next Five Years..." keynote from TSSJS. Thanks, Darryl.

Update: Just noticed that Darryl also covered Brian's and my "SOAP and REST" talk, as well.

I hate Las Vegas.

I'm here for TheServerSide Java Symposium 2008, which has been held here in Vegas for the past (umm... three? four? five?) years, and every time I come here I'm reminded why I really don't like Vegas. It's loud, both in auditory volume and visual noise, it's boisterous bordering on raunchy, the locals are almost always soured by their near-constant exposure to tourists, the tourists are... well, they're American tourists and that says a lot right there, and there's no way to escape it. Ugh.

Fortunately for me, the hotels have conveniently painted a nice blue sky on the roof (in the Venetian, where the conference is held) so I don't have to go outside to see if it's sunny, they provided a nice winding river of bright neon blue water/Windex to have our leisurely cafe lunch next to, and no fake recreation of Venice would be complete without fake gondolas poled by fake gondoleers singing to tourists on the fake Windex river that's all of about two minutes in ride length before they have to do a U-turn and pole back the other way.

Wow, it's all so magical.

About the only thing that makes Vegas palatable is some of the shows you can catch here, like one of Cirque du Soleil's six (!) different presentations going on here. But, of course, you must be careful when you buy tickets, or the guy at the concierge desk will start finding tickets for you, only to discover later that he thought you said "Tah", meaning "Tom Jones", when you said, "Ka", the Cirque du Soleil show, because my California accent is too thick to be understood.

I hate Las Vegas.

The upshot is that when I'm here for this show, I get to hang out with some cool people, NFJS speaker alum and otherwise. Brian Sletten and I did a tag-team talk on SOAP and REST that was billed to be controversial but probably disappointed the crowd in that we didn't (a) throw any punches at one another, (b) didn't really proclaim a "victor" between the two, and (c) laid down some basic rules for when to look to a RESTful approach and when to take advantage of the existing SOAP-based infrastructure that is currently SOAP's greatest strength.

Note to those who didn't attend the session: you didn't hear me say it, so I'll repeat it: I hate WSDL almost as much as I hate Las Vegas. Ask me why sometime, or if I get enough of a critical mass of questions, I'll blog it. If you've seen me do talks on Web Services, though, you've probably heard the rant: WSDL creates tightly-coupled endpoints precisely where loose coupling is necessary, WSDL encourages schema definitions that are inflexible and unevolvable, and WSDL intrinsically assumes a synchronous client-server invocation model that doesn't really meet the scalability or feature needs of the modern enterprise. And that's just for starters.

I hate WSDL.

I still hate Vegas more, though.

Meanwhile, Glenn Vanderberg, NFJS speaker alum and current Chief Scientist over at Relevance, pulled me aside for a few minutes to show me how to build apps for the iPhone using the newly-released iPhone SDK (something I'd asked about once before and that's been exploring recently). We basked in the glory that is Objective-C (now there's a language that should have gotten more traction than it did, IMHO), and then in the glory that is the iPhone (OpenGL, OpenSA, which I didn't know but Glenn tells me is basically like an audio-equivalent library for OpenGL), and then we swapped some ideas about what people might do with the iPhone now that the SDK is available. I've always been pretty bullish on the mobile device market, and I still am, but the iPhone might be the turning point in that space. I'll reserve judgment for now, and just enjoy hacking on my own for the time being.

Neal Ford did the Wednesday morning keynote, and I got the chance to present "Why the Next Five Years Will Be About Languages" after lunch today, which seemed to go over well, at least based on what the attendees who came up to me afterwards were saying. (Of course, that's always a biased assessment, since the ones who hate it are hardly likely to come up and tell me that, so I always take that statistic with a grain of salt.) They videoed it, so I imagine it'll be online before long.

Of course, TSS wouldn't be TSS without speaker panels saying really controversial things... but I wouldn't know about them this year, I wasn't on any. (Perhaps the conference organizers finally took everybody's advice...)

Tomorrow (well, actually, today as I write this, since I'm up way too late as usual) I'll be doing a talk on Scala, having dinner with a few friends, then off to McCarron airport and home. I don't think the Scala talk will be taped, but you can catch me doing much the same stuff (well, as much as it ever is the same stuff when I speak, since I mostly make everything up on the fly anyway) at the NFJS symposium near you, so you don't have to come to Vegas to hear about it in between ducking packs of drunk twenty-something guys chasing packs of drunk twenty-something girls all the while dodging the attentions of finger-snapping sidewalk vultures handing out glossy business cards saying "Girls Direct to You".

I so hate Vegas.

Update: Hah, that'll teach me to blog that before the conference is over--Eugene and Joe drafted me into the final panel session of the conference, on "Cross-Cutting Concerns, a Multi-Disciplinary Approach to Java", which none of us--including our emcees--had any idea was supposed to be included in such a discussion. Glenn Vanderberg and Patrick Linskey then sought to take a vote and change the topic of the panel to "Shearing off Ted's Ponytail". Fortunately a kind attendee asked a question and we moved on, ponytail intact.

Of course, given that this was Vegas, I probably could have gotten Carrot Top to do it and made some money on the deal.

Apparently, I'm drawing enough of an audience through this blog that various folks have started to send me press releases and notifications and requests for... well, I dunno exactly, but I'm assuming some blogging love of some kind. I'm always a little leery about that particular subject, because it always has this dangerous potential to turn the blog into a less-credible marketing device, but people at conferences have suggested that they really are interested in what I think about various products and tools, so perhaps it's time to amend my stance on this.

With that in mind, if you are a vendor and have a product that you'd like me to take a look at and (possibly) offer up a review here, here's the basic rules:

1. No guarantees. Sending me something will in no way guarantee that I will review your product, for several reasons, two of which being (a) I get really busy sometimes, and (b) I may have no interest whatsoever in your product and I refuse to pretend to do so. (Readers can usually tell when the reviewer isn't all that excited about the subject, I've found.)
2. If you're not going to send me a "real" version (meaning not the time-locked or feature-crippled demo), don't bother. I have no idea when I will get around to a review, and I have no desire to review something that isn't "the real deal". I will in turn promise that the licensed version you send me (if necessary) will not be used for any purpose other than my own research and exploration (signing contract if necessary to give you that "fresh-from-the-lawyer's-office" warm and fuzzy feeling).
3. I say what I think, pro and con. I will not edit my review to suit your marketing purpose, and if you ask me to do so I will simply note in the review that you have asked me to do so. I retain full editorial control over what I say about your product.
4. Having established #1, I will try to be as fair as I can about your product, and point out things that I liked and things that I didn't. (Of course, if I hated it from top to bottom, I may end up with the only positive thing being "It didn't set the atmosphere on fire when I started the app", but hey, that's something positive, right?)
5. Also in the spirit of #1, if you send me mail answering questions or complaints in my review, I will of course amend the review with your comments. You are always welcome to post comments to the blog entry itself, too. Unless you insult my grandmother, then I will have to get all DELETE-key on you.

The reason I'm posting this here is twofold: one, so my faithful audience of four blog readers will know the rules under which I'm looking at these products and (hopefully) realize that I'm not financially vested in any of these products, and two, so the various vendor folks can read this and know what the rules are up front before even asking.

I know it sounds a little cheeky to lay this out. The image I get in my head is that of the kid at Christmas declaring to his grandparents as they walk through the door, presents in hand, "Make sure it's not a scratchy sweater, I hate scratchy sweaters. And G.I. Joe was only popular when my Dad was a kid. And if you give me another lunchbox I will scream until you buy me something cool, like a new GameBoy." Ugh. But I value the trust that people seem to have in me, and so I risk the perception of cheekiness for this tiny window in time in order to (hopefully) establish full disclosure over the reviews that come to pass (which, by the way, will always have the category "review" applied to them, so you know which is an official review and which is just me exploring, like the LLVM and Parrot posts of recent time).

We now return you to the regularly-scheduled blog.

For those who were skimming my blog looking for the notification that the Lang.NET 2008 Symposium videos were back online, look no further.

A couple of people have asked me over the last few weeks, so it's probably worth saying out loud:

No, I don't work for a large company, so yes, I'm available for consulting and research projects. If you've got one of those burning questions like, "How would our company/project/department/whatever make use of JRuby-and-Rails, and what would the impact to the rest of the system be", or "Could using F# help us write applications faster", or "How would we best integrate Groovy into our application", or "How does the new Adobe Flex/AIR move help us build richer client apps", or "How do we improve the performance of our Java/.NET app", or other questions along those lines, drop me a line and let's talk. Not only will I cook up a prototype describing the answer, but I'll meet with your management and explain the consequences of the research, both pro and con, for them to evaluate.

Shameless call for consulting complete, now back to the regularly-scheduled programming.

This delicious little tidbit just crossed my desk, and for those of you too scared to click the link, check this out:

Microsoft will begin collaborating with the Eclipse Foundation to improve native Windows application development on Java.

Sam Ramji, the director of Microsoft's open-source software lab, announced at the EclipseCon conference in Santa Clara, Calif., on Wednesday that the lab will work with Eclipse .

The goal of the joint work, which will include contributions from Microsoft engineers, is to make it easier to use Java to write applications that take full advantage of the look and feel of Windows Vista. Ramji wrote about the planned collaboration on Microsoft's Port25 blog.

"Among a range of other opportunities (which we're still working on), we discovered that Steve Northover (the SWT team lead) had gotten requests to make it easy for Java developers to write applications that look and feel like native Windows Vista. He and a small group of developers built out a prototype that enables SWT to use Windows Presentation Foundation (WPF). We're committing to improve this technology with direct support from our engineering teams and the Open Source Software Lab, with the goal of a first-class authoring experience for Java developers," he wrote.

The move builds on several initiatives coming from Microsoft's open-source software labs to ensure that open-source products work well on Windows and other Microsoft products.

My first reaction has to be characterized as... WTF?!?

My second reaction has to be characterized as... WTF?!?

There's some serious credulity issues here. Not credibility, mind you, because I believe the reporter is entirely accurate in this story, but credulity. As in, "That's incredulous!", which is another way of saying...

WTF?!?

First, it's not been that long ago since Microsoft and Java were actively trying to beat one another into something vaguely resembling... well, resembling either a strawberry after that oh-so-ill-advised blind date with a blind steamroller, or else the end-product of the local butcher's sausage grinder. I seriously doubt anybody's memory has lapsed so deeply that they forget the rather nasty shooting war that erupted over J++ and Microsoft's Application Foundation Classes.

(For those of you who weren't writing Java code at the time, AFC was Microsoft's variation on AWT designed to make it easier to write native Windows apps, making heavy use of a language/library construct that was an extension to Java, known as "delegates". Yes, those same delegates as what appeared in C# a few years later, and those same delegates that became the core implementation behind C# 2.0's asynchronous methods and C# 3.0's lambda expressions, and arguably the same delegates that everybody is looking to incorporate into the Java language today. Funny how things turn out, no?)

Second, Microsoft partnering with IBM (yes, I know, the news piece says Eclipse, but who runs most of the Eclipse projects? IBM is to Eclipse what Sun is to the JCP, folks) to do this is just not going to make the whole IBM-Sun rift any smoother, or calm the turbulent waters in the Java ecosystem any further. Granted, SWT, is the logical place for Microsoft to go when trying to make it easier for Java devs to write Windows apps (which, by the way, was always a core principle behind the design and implementation of the CLR, which is why the CLR has such a powerful and simple P/Invoke and COMInterop story), but the last thing Microsoft wants at this point, it would seem to me, is more controversy around it and Java. After all, how hard would it be for Sun to haul them into court again, claiming that this somehow violate's the Microsoft/Sun peace agreement of a few years ago?

And while I applaud the fact that Microsoft is looking for ways to contribute to the open-source space, it just seems to me that there were a lot of other places they could have gone to start doing so without incurring this kind of reaction. Go write a standard Perl implementation, for example, or, even better, do a "Visual Lisp" and integrate it on top of the CLR, if you want to make a mark in the open-source world. There's thousands of places the gathering-steam Microsoft open-source direction cou