Slashdot Mirror
Inside Microsoft's New F# Language
robyn217 writes "There's a new language being formed in the bowels of Microsoft. Recently I got word that the language F# (pronounced F Sharp) is nearing workable stages at Microsoft Research. So, I went in for a look-see. What I found was an interesting blend of imperative (Java, C#) and functional languages(it's ML-based, too!). It looks pretty enticing to me from a computer science perspective, but I'm not sure it would fly in the professional market. I can see the ease of development that a language loosely based on ML would bring, but I can't see coders switching over in droves since it's a tough learning curve." Our previous story on F#.
A microsoft rep met with us a couple of weeks ago pushing .NET, win2k3, the whole enchilada. He mentioned they have MANY of these languages in development and are due to be released in the next year or so. They will still be pushing C# for mainstream development. The other languages will focus on niches where a modern OO language would be cumbersome.
;)
He wouldn't confirm whether they would have the X# naming convention
Actually, after rereading, doesn't python's lambda or use of functions as objects address the same problem space as F#? (per the author's example on the "What's the purpose of F#?" page of the article? My python's rusty, but, isn't that one of the cool things about python? Couldn't a C# delegate do something similar? Can you tell VB is my native tongue? :-)
This space for rent.
Our company has recently started to introduce .NET development alongside our core J2EE platform. One of the issues that has come up has been how useful the multi-language/single-platform support would be. Rather than taking a "best of breed" language for all development, the use of the right tool for the right job could potentially lead to interesting results - A mix of C#/ML/PROLOG/etc. as appropriate for the immesdiate task at hand. I don't think MS is far enough down the road yet to capitalise on the idea, but it's certainly an intriguing possibility - Even if it would lead to a maintenance nightmare :)
Map then applies whatever function we pass in to every member in the array (called a list in functional programming).
So, all you functional programmers, remember... a list is just another name for an array :-P
Seriously, though... I was discussing the future of programming languages with some friends and we agreed that a real step forward would be to provide features such as higher order functions in a mainstream language... could this be it?
If so then it's a little worrying... I'd rather not see any revolutionary languages come out of MS, if at all possible...
(Cambridge's Computer Science degree teaches ML followed by Java in the first year... would they switch to teaching just F# if it became popular?)
I wonder if F# has any relationship to the "ML for Microsoft" (I forget the name) efforts from Harlequin Software a few years ago? ML has always seemed an ideal fit for many single-user RAD developments, it just needed an appropriately stable, complete, clearly specified component library and professional quality IDE in order to reap productivity benefits over Java/C# et al.
As one of the posters above mentioned, python's lambda is actually borrrowed from the Functional programming world. I believe it originally gets its name from Lambda Calculus, but mathematicians will have to correct me on that. (I first saw it in Scheme, the most beautiful programming language I've ever programmed in, if not the most practical.)
If you've never done functional programming, it a different animal from imperitive programming, and if you do know python, it borrows a number of things from FP, not just lambdas. Look at python's map, apply, and reduce functions, along with list comprehensions (taken from Haskell, which I really need to learn). Although, it should be noted that python's recursion really isn't optimized for FP, but you can still do quite a few things that a functional programmer would be at home with.
no comment
It's usually a very bad idea to include imperative aspects in functional languages.
Functional languages are amazing creatures. They're really strange to work in. They take a serious change of mindset. They can be very slow to execute. I/O is really odd when side effects are forbidden.
They have astounding benefits, too. The localization of effect means that they're really easy to debug. The lack of side effects means that some really enormous optimizations are open, which is crucial since the naive execution is slow.
Once you throw in any imperative aspects at all, these effects go right out the window. Even a single imperative statement potentially interferes with every optimization. ("Can I eliminate this execution branch? It seems like a redundant call but it might branch to that imperative statement.")
I think that this got in the way of ML. It can be easy to want to add just a tiny imperative element to make something easier, but that small crack opened up a lot of headaches for me. I greatly preferred the purity of Haskell.
I haven't read the F# spec, so I may be overreacting from the notoriously inaccurate Slashdot summary. That's next.
Functional Programming is a Very Good Thing to learn.
After being interested in functional programming languages for a while I had the opportunity to spend some time reviewing a textbook using ML. I figured that was the time to learn the language. Got frustrated quickly, I got several ML systems (including the one mentioned in the book) and no two worked alike. Hell, the syntax varies enough that there are ML dialects that look like completely different languages.
A while later I decided that perhaps it was time to spend some energy seriously learning Haskell. I got and installed Hugs (Haskell.org is a wonderful resource with several Haskell systems listed, tutorials, documentation, libraries and so on). Hugs implemented pretty much all of the Haskell described in the manual I found and the tutorials. (Today, I'd probably use the interactive GHC.)
It took a while, some dedication and a lot of grumbling to figure out how things worked and I'm still learning bits and pieces of the language and associated libraries and stuff.
Now Haskell is one of my favorite languages and I want to use functional tools (higher order functions, laziness, and so on) in every language I use. I'd say that Haskell changed my ideas about programming, my approach to problems, and my toolset both deeply and widely - and for the better. Probably as deep a shift in technology and technique for me as OOP (I started programming in Fortran, APL, Algol...) - but then OOP just always seemed Right to me.
Part of what made the learning process so effective was that Haskell makes it very hard to have side effects - so where in ML the books/tutorials often introduce mechanisms for building variable that work more or less like those in C - in Haskell this is very difficult.
So, while F# may be an interesting language, if you want to learn a new language, try Haskell. You may have to be obstinate. And if it works with you as it did me, it will drive you crazy until it clicks (and I remember exactly the problem that did it) and then you'll just kind do one of those quiet awestruck "wow"s and watch your view of programming change.
Haskell isn't the right language for everything. I also use Java, C and Python (and a few others) often - but for lots of problems, for doing a quick model of something to try it out, for just helping your mind think about a problem a bit differently ... Haskell is great.
But remember - you may well have to be stubborn about persisting till it clicks.
And on a related note...
Does anyone know if anything ever came out of the development of the functional scripting language "Sheep" for the amiga?
can't connect them to real I/O
This used to be true ten years ago, but you are way out of date. OCaml works great for I/O. If available Debian packages are any measure, OCaml has had quite the active and growing developer base too.
The major semantic hurdles for even (mostly-)pure functional languages (c.f. Haskell) were solved many years ago. (Look up the papers of John Launchbury, Simon Peyton-Jones, and others on State Transformers in Haskell. See also papers about how the use of the 'monad' from category theory introduced an incredibly powerful tool into languages such as Haskell). The Fox project at CMU used Standard ML to create a nifty layered TCP/IP stack and HTTP sever back in the mid 90's.
The various current functional languages may have issues, social and/or technical, w.r.t. mass adoption... but the I/O problem definitely isn't one of them anymore.