Lambda the Ultimate

It seems pretty lame if these abstracts don't indicate where I can grab the bits and try out the ideas. Otherwise it is just handwaving marketing fluff to say "hey, functional programming is cool".

I find it odd that you will blithely endorse Direct Logic, which, as near as I can tell, lacks an implementation, but trash some other idea for the same short-coming. (And what there is has trademark signs on it.)

But hey, cloud-computing is cool.

I went to the CUFP 2010 website (which Yaron did not provide a link to) and read the Eden abstract, because I was interested in it. Here is a link to the abstract for Eden.

I am not trashing Eden, since I don't know what ideas it represents. I am simply commenting so that the organizers can improve how they organize things. CUFP is fairly progressive insofar as computer conferences go, since last years talks were all digitally recorded and provided for free to passers-by.

All I am saying is I would like to know how I can grab the bits for something and play around. The abstract doesn't tell me much. Video presentations tell me something, but usually not enough.

you will blithely endorse Direct Logic

Incorrect. I did not provide a value judgment for Direct Logic. I simply stated the consequence of the math. I don't know what you work on for a living, so to bias you with my own value judgment would be especially wrong-headed, as it might be a formalism valuable to you but not to me. Bottom line: I did not say whether Direct Logic was good, bad or ugly.

But hey, cloud-computing is cool.

I think cloud-computing is a fad, but this is something we should discuss in private (or at least not in this thread).

It's reasonable to ask that a distinction be made between what is and isn't available to the public in some concrete form. But this goes too far:

Otherwise it is just handwaving marketing fluff to say "hey, functional programming is cool".

That's a rather trivialized view of the purpose of workshops and conferences. Not all ideas are exchanged in the form of executable code, and that's not even a reasonable goal to aspire to.

The exchange of ideas that aren't necessarily available in some concrete form is fundamental to progress. The notion that this is "just handwaving marketing fluff" is bizarre. Particularly at a workshop devoted to the Commercial Users of Functional Programming, where the proprietary nature of the work under discussion tends to be the default situation.

I acknowledge my phrasing was like an ogre.

Particularly at a workshop devoted to the Commercial Users of Functional Programming, where the proprietary nature of the work under discussion tends to be the default situation.

Most of the presentations seem to involve projects where you can download a binary or source code for. The default situaton in 2010 is open source, possibly free/libre. Even Credit Suisse is fairly open about their ideas. The gist of my point was:

(a) don't copy-and-paste the CFP
(b) improve the website so that you'll want to link to the website instead of copy-and-paste the CFP
(c) here is one way you can improve the website

If it came out sounding bizarre, it's because that is how I sometimes communicate, and usually regret it.

Most of the presentations seem to involve projects where you can download a binary or source code for.

Is that a good thing, though? Some of the most interesting projects I've ever seen have been decidedly not open source. If there's pressure to provide source, and a bias towards presentations that do, then conferences involving commercial presenters will tend to be limited either to projects with minimal commercial value, or to those that naturally lend themselves to an open source approach. This excludes large classes of important and interesting projects.

I don't care if a company open sources their F#/WPF project. Most WPF code I've looked at is pretty bad (because many parts of WPF are pretty bad). Most of the reasons I consider the code bad has to do with how people abuse WPF. Just the other day I found a ridiculous piece of WPF on an old MSDN forum post where some company based their entire so-called "architecture" on Adorners, and were bitten by the fact Adorners appear to have a static limit of 144 layers. Likewise, some "F# geometry abstractions" libraries I've seen aren't too impressive.

Actually, from experience, I can tell you the only reason I've integrated F# with WPF is for structural typing, partial application and pattern matching features not available in C#. F# has handy built-in syntax for working with CIL types when pattern matching, too. In short, by mixing F# with pre-existing C# code, I get a feature set approximating Scala without having to beta test Scala.NET. Through the use of an IoC container and F#, I can generally hide from my main application not only what modules I am loading but also hiding the decision of what visualization to choose from how to visualize it (e.g., WPF vs. Sivlerlight implementations). One thing I did awhile back to make this easier was entirely unrelated to F#: I figured out the mapping of interfaces between WPF and Silverlight and used that to keep track of Silverlight changes, since MSFT does a horrible job telling customers about changes. In addition, I then used the diff to auto-create FxCop custom rules to flag possible WPF code that wouldn't be easily portable to Silverlight; warnings would suggest Silverlight idioms instead and also try to characterize the differences.

Those sorts of concepts are shareable. I am not as confident that sharing APIs through "ideas" are as shareable. For one, usually you'll want to trace the idea back to its source rather than take it in "upstream" form. For two, I can speak from experience trying to round up ancient graphics APIs that the less code you have to look at the more wishy-washy a paper reads.