Lambda the Ultimate

that it took Microsoft of all things to get the wonders of fp across to a bigger community? i mean, it seems like the progression of C#, LINQ, F# has done more to introduce to and indoctrinate people in the goodness of good fp stuff than any previous attempts. funny.

..but then again, I blame Sun for everything ;)

...if it doesn't run on Linux, then it's at a substantial ($$$) handicap to be run at web-scale. There's a reason Twitter and LinkedIn are using Scala, and not F# (or even OCaml). That's where to place your chips.

I'm not placing my chips on Scala. Then again, I'm not "placing my chips" on F# either.

I've been using F# a bit lately, and I have rather mixed feelings about it, technically speaking. I'm rather skeptical that moving from C to .NET as the least-common-denominator for intra-process language interoperability really is an upgrade.

Politically speaking, I have mixed feelings about it. On the upside (and it is a big upside) I really do not think that F# competes with Lisp/ML/Haskell. My belief is that it won't siphon developers away from these languages but rather grow the size of the community considerably. So that really does get me excited. On the other hand, you do occasionally hear or read incredibly obnoxious remarks that FP was never ready for prime-time until F# came along. But the remarks of a few small-minded ignoramuses is a pretty small downside, really.

For whatever reason, this kind of story repeats itself over and over again: microcomputers are mere toys until IBM blesses them, perfectly good 64-bit architectures with existing code bases must be replaced with AMD x64 that didn't have a code base before we could move to 64 bits, etc etc.

On the other hand, you do occasionally hear or read incredibly obnoxious remarks that FP was never ready for prime-time until F# came along. But the remarks of a few small-minded ignoramuses is a pretty small downside, really.

I think this just means that F# provided a sufficiently low barrier to entry, ie. familiarity with the featureful .NET base class libraries, that ordinary C# developers could jump ship with less effort than jumping to SML, OCaml or Haskell. The learning curve is just so much lower, which is valuable in itself; the conclusion that SML/OCaml/Haskell is therefore not ready for "primetime" does not follow, though there are some legitimate concerns in this direction, most notably, the difficulties surrounding dynamics, ie. dynamic code loading, serialization, etc. These are heavily used features of the JVM and .NET.

I think this just means that F# provided a sufficiently low barrier to entry, ie. familiarity with the featureful .NET base class libraries, that ordinary C# developers could jump ship with less effort than jumping to SML, OCaml or Haskell. The learning curve is just so much lower, which is valuable in itself; [...]

This is certainly part of it. After all, I'm biased in my reservations about .NET because I know C much, much better, so for me personally the learning curve for F# is relatively higher than say, learning OCAML better. (as I've mostly worked with SML)

Of course, there is also the issue of simply being endorsed by Microsoft as a full citizen in their product line. If nothing else, it makes it a much easier sell to certain kinds of bosses and/or customers.

Every implementation has it's strengths and weaknesses; with few exceptions, dismissing any given implementation out of hand for every possible application is silly.

On the other hand, you do occasionally hear or read incredibly obnoxious remarks that FP was never ready for prime-time until F# came along. But the remarks of a few small-minded ignoramuses is a pretty small downside, really.

That's below you, and not what Rauld said. Read again.

I was not referring to raould's remark in that sentence. The whole of my reply agrees with him. That remark was a tangential to the conversation, and I don't recall ever seeing the kind of remark that I referred to on LtU.

A: F# what? What the f*** is this?
B: a functional programming language.
A: what about our other languages? Are they dysfunctional?
B: no it's just that in F# functions become pure or first class or something like that.
A: I don't understand.
B: I don't understand either but we shall sell it.
A: Oh...

silence

A: does anyone use those functional programming languages?
B: not that I'm aware of. No ... Yeah, computing scientists use them a lot and they have been a source of inspiration for LINQ!
A: Yeah, LINQ is cool. But scientists... I don't know.
B: We can say "F# is a revolution".
A: We always say this about everything but we don't sell our products to scientists.
B: Hmm...
A: What about "With F# functional programming is ready for prime time!"?
B: Wow, that's great! Now, all those office guys will listen.
A: The scientists will be offended but ...
B: ... but who gives a shit?
A: Done.

I'll start off with your initial A

A: F# what? What the f*** is this?
B. It's based off a language that eggheads in academia use
A. And why are we productizing this?
B. The same reason we spend lunch money to have a few guys work on .NET version of Ruby and Python
A. What's that?
B. Something the open sores play with on Linux
A. How does this make us money?
B. It probably won't, but remember when we got caught with our pants down in the mid 90s regarding the internet.

silence

A. So what's the difference between this and all these other new-fangled thingies that the eggheads are playing with?
B. We actually provide a proper environment to program in it.
A. Environment?
B. Yeah, we provide intellisense and all the other cool stuff that is in Visual Studio
A. Can't they just use Emacs?
B. Emacs????
A. Does any of this matter?
B. No, but we don't want to look like Sun and Java
A. Done.

+1 to parent.

A contemporary language is considered beyond its syntax and a compiler, be it F# or Scala--really good tools are needed to support that language, which requires real resources. Any commercial company deciding to dedicate resources to functional programming should be considered a good affirmation of FP (disclaimer, I work for MS). FP can and should evolve beyond its ivory tower and specialty programming niche to become more mainstream.

Why FP getting more interest now? Multi-core, GPUs have changed the rules of the programming game and imperative doesn't cut it anymore. Many companies are looking at ways of dealing with this, and FP is becoming a major contender for the solution problem. This battle is very important, because the other primary contenders are C/C++-throwbacks (CUDA, OpenCL, HLSL Compute).

Basically, nobody realizes how talented the folks at MS Research are. Only recently are a lot of long-term initiatives paying off (i.e., CHESS, Terminator). Craig Mundie seems to be doing a great job.

I'm not sure I understand exactly what evokes disturbance here. Can you elaborate? In terms of functional programming trickling into the mainstream general purpose programming community, well, it's trickling.... Microsoft entering the functional evangelism game means more of a sustained flood than a constant drip.

Charles

[warning/apologies: longish, rantish...]

[edit: summary: NIH pisses me off!]

i worked at msft for just under 5 years, using C/C++/C#. of course i did not get a feel for the entire culture, and i was not working at the Redmond (mothership) site. but my opinion of the core culture was that i was not overly impressed with the day to day use of useful, important, or advanced techniques from the PLT arena. it did happen sometimes, but it was pretty rare. i am not that big a PLT nerd and yet i was the "roll our eyes at the haskell guy" receiver. :-) so i was surprised that it started happening at MSFT outside of MSR. good going, MSR!! keep it up.

it is disturbing to me in that (a) it took so long for PLT to get anywhere main-stream (b) there were so many opportunities for it before from "non-evil" if you will (i realize that is not really a relevant subject for LtU but it is in my thinking in this topic anyway) places which apparently for the most part utterly failed to gain traction (c) history is written by the juggernauts: the msft devs will claim they are doing this new wonderful thing that sorta nobody has apparently ever done before and we should love them for it.

i went though this with C#/.net; i was doing training as an MSFT employee to learn up on .net and i felt (and others in the class who were language nerds did too based on their comments in class at the time) that the attitude was "we just invented garbage collection! bow to us!" rather than "wow, there are these great ideas that have been out there for ever, that a zillion other people have done a lot of groundwork on, here we are standing on the shoulders of all those previous people, let us take a moment to think about them and thank them -- oh and we have a few additional Good New Ideas of our own that we modestly want to introduce to the world."

oh well. at least it is happening at all. (although that kinda sucks because there goes one of my secret weapons!)

This doesn't reflect my experience, spend any amount of time with the Microsoft PLT guys and you'll find that they are pretty well versed with what's out there, most of them are strong PLT'rs with well known backgrounds (e.g., Erik Meijer). Your experience in the classes was probably with professional teachers who in general are getting paid to teach to the mostly clueless. You weren't the intended audience, and in general I try to avoid those classes like the plague, because I'm pretty sure I would react in a similar way.

I'm going to guess that a lot of the recent FP promotion coming out of Microsoft is aimed at Microsoft's core developer audience, which hasn't been very accepting of FP in the past. They are catering the message to this audience, and again this audience is definitely not you or me. But expanding the FP tent is good for everyone as it will eventually give us PLT'rs more of an audience for our work.

i guess another way of saying what i feel is that MSR is very different from the rest of MSFT, and it is good that MSR is getting things out to the world, but it is annoying that it goes through the "we invented this all on our own!" NIH filters that i think MSFT has in spades.

but i'm not contributing anything PLTy here, so i'll shut up now.

Lazyness will be the subject of a lecture in its own right later on (chapter 12).

Doing things explicitly and as soon as they are mentioned is a nice way to let the programmer be able to predict what on earth their program will actually do when it runs. There's a fair bit of wailing and gnashing of teeth over "oh this laziness just blind-sided me" I feel, even if it is so very appealing from a math/purity standpoint.

There's a fair bit of wailing and gnashing of teeth over "oh this laziness just blind-sided me" I feel

Not about semantics in a pure language...

cf. reported confusion in Haskell; maybe the semantics are defined but are too confusing and liable to change for mere mortals to keep correctly in mind all the time?

It can be difficult to reason about pervasive laziness in some cases, but it's also difficult to assess that properly from the perspective of intuitions and preconceptions gained from working mostly with strict languages. A lot of the "confusion" about laziness seems to be due to that bias.

Haskell shows quite clearly that both laziness and strictness are useful, in the same program, so if your conclusion about confusion due to laziness is that laziness should be avoided, I'd disagree.

Instead, I think that languages and tools could help more with managing laziness. Don't forget that Haskell is a testbed for this kind of thing, and that approaches to dealing with it are evolving.

The runtime semantics are fairly important; not sure what you mean by 'semantics'. As I write programs for people to run, I need to know around when my program terminates (and if it does). Laziness is a syntactic boon for many control patterns... but, apparently, also a curse. The concurrent discussion on SequenceL and my experience with transparency ('lifting') in FRP are similar: global transformations give you a lot, but often at a steep expense that we are too quick to trivialize.

...call-by-value (and call-by-name) have compositional performance models: you can calculate the performance of an expression in terms of the performance of its subterms.

This is not true of call-by-need, since the run time of an expression depends on whether or not its thunk has been evaluated already, or not. In other words, you have to reason about aliasing in order to reason about performance!