Summary
F# is Microsoft's new functional programming language targeting the .NET platform. In a recent blog post, Luke Hoban, manager of Microsoft's F# compiler team, introduces some of the more interesting features of this language.
Advertisement
F# is a strongly-typed, functional programming language designed by Don Syme and James Margetson. Initially a project at Microsoft's research lab, F# recently received the blessing of Microsoft's developer tools division to evolve into a full-fledged language supported on the .NET runtime.
Luke Hoban, manager of the F# compiler team, wrote a short blog post about some of the more interesting features of this language:
One of the most striking features of F# code is that it is very terse - ideas can typically be expressed with a small amount of code. There are a few significant language features which contribute to this:
Type Inference:
F# is strongly typed, like C#, but instead of having to declare the type of variables, parameters and return types, F# uses type inference to determine these automatically. When the types cannot be inferred, type annotations can be supplied in the code...
#light: The #light directive in F# allows code to omit begin...end keywords and some other tokens, and instead relies on indentation to indicate nesting. This is similar to languages like Python, and enables the same kind of syntactic lightness that programs in these languages enjoy.
Expressions: F# programs are built out of expressions, which can be composed very simply. For example, if is an expression in F#, as opposed to in C# where it is a statement. This can make code simpler, while also enabling a high degree of flexibility.
Hoban points out in his blog post that F# programs can access any .NET type, but that F# itself supports additional types, too:
F# is built on the .NET type system, and provides access to any type defined in a .NET assembly. Types can also be defined in F# using the keyword type. There are many kinds of types that can be created in F#, for example, standard .NET types such as classes and interfaces can be defined, but F# also supports types such as records and discriminated unions.
As with types, F# can access any .NET library, and it also has its own set of standard libraries:
F# code can use all of the exisiting .NET libraries, such as the Console class... But F# also has access to a rich set of F# libraries, providing types that are well suited to functional programming and F# in particular. A few notable libraries:
Math: One very useful example is the F# math libraries, representing datatypes such as Vector, Matrix, and BigNum, as well as the Complex numbers used in the code above.
Collections: The standard .NET Framework collections can be used from F#, but there is also a fully-featured set of functional collections, including the ubiquitous immutable linked list (List), an efficient immutable set built on binary trees (Set) and an immutable dictionary (Map)
> Do you think there is enough interest in functional > languages to make F# a mainstay .NET language? be it let x : int ref = ref 4 in x := !x * 2; !x ;;
or int x = 4; x *= 2; return x;
How much difference does it make? Granted, that's some very bad OCaml, but that's how joe programmer will write his OCaml if we push him to, and joe programmer write 80% of the boring software out there. Java isn't that bad as a language.. ok it's that bad, but you see "really" bad java code most of the time, so the problem is not "always" with the language. I can understand the necessity of powerful languages for sharp people like those from Galois Connections, or Jane Street Capital, but not for writing the programs I write everyday(CRUD, gui and a set of simple business rules that I'd refactor into a strategy design pattern instead of if then else branches, because I like being sophisticated ), I never had to write any algorithm if you want the truth, that's the kind of software I'm writing. So what do I care if I have to use a catamorphism in place of a for loop ?
"So what do I care if I have to use a catamorphism in place of a for loop ?"
You should care because these types of languages(*) allow library writers to write better libraries -- which then enable you to make your code even simpler and more readable.
(*) Well, not so much F#, but referentially transparent languages with good type systems (e.g. Haskell) enable some truly amazing stuff. See HAppS for instance.
> <p>Do you think there is enough interest in functional > languages to make F# a mainstay .NET language? </p>
I don't think most programmers even know what a functional language is or have any interest in studying those, let alone wrote any code in one. Anyway, ever since Java came out a bunch of new languages have been created: J#, C#, F#, Scala come to mind. Most new programming language propaganda sounds something like "... read the tutorial, try writing a few small programs using this or that feature and you will see how great this programming language is!". My question is Would type inference, IF expressions, first-order functions and closures, lazy evaluation or any other FP construct really make our large-scale systems easier to write, understand and debug? These constructs are definitely useful, but none of the recent posts I read brings these questions into focus. Instead, they all talk about isolated features that might look attractive on the surface but not offer much help when (necessarily) combined with other constructs in order to create a large system. It looks like there is a tendency these days to complain about the programming language whenever there is almost any kind of problem that would seem to be easily solved if the language just supported this or that feature. I'm pretty sure most or all of those problems have nothing to do with the programming language being used, but a lot to do with understanding the problem, correctly structuring the code, following proven design principles, using the appropriate algorithms and data structures, and using the right tools. As someone once said: There are two kinds of programming languages - those that nobody uses and those that everyone complains about.
> I don't think most programmers even know what a functional > language is or have any interest in studying those, let > alone wrote any code in one.
Most people didn't know what OO or Java were when they first came out.
> I'm > pretty sure most or all of those problems have nothing to > do with the programming language being used, but a lot to > do with understanding the problem, correctly structuring > the code, following proven design principles, using the > appropriate algorithms and data structures, and using the > right tools.
So we should all still be programming in C or assembler?
When I changed my main language from C to Java, it wasn't about a few new features, it was about the way I thought about structuring a system. I think the same is true with F# and Scala. It's not about a few new features, but a different way of thinking about coding.
> > I'm > > pretty sure most or all of those problems have nothing > to > > do with the programming language being used, but a lot > to > > do with understanding the problem, correctly > structuring > > the code, following proven design principles, using the > > appropriate algorithms and data structures, and using > the > > right tools. > > So we should all still be programming in C or assembler? > > When I changed my main language from C to Java, it wasn't > about a few new features, it was about the way I thought > about structuring a system. I think the same is true with > F# and Scala. It's not about a few new features, but a > different way of thinking about coding.
My point is that when implementing a *large* system you cannot think in FP way or OOP way or any single way all the time. You need to think in many different ways and you need a language that allows you to do that. Whether F# is such a language remains to be seen, although, frankly, I'm skeptical since the language is marketed as functional, i.e., a single-programming-style language (however, I don't know F# so I'm not going to judge it). Switching from one language to another is in many cases just replacing one set of problems with another and I personally don't buy into that kind of stuff. I've seen too many of the same problems (mostly those I mentioned above) in user groups of all kinds of languages (like Java, C++, C#, Visual Basic) which convinced me into what I said in my post. I'm not aware of any strong evidence that FP by itself, or any such language, improves this situation significantly, if at all. If you know otherwise I'd certainly like to learn about it.
> It looks like there is a tendency these days to complain > about the programming language whenever there is almost > any kind of problem that would seem to be easily solved if > the language just supported this or that feature. I'm > pretty sure most or all of those problems have nothing to > do with the programming language being used, but a lot to > do with understanding the problem, correctly structuring > the code, following proven design principles, using the > appropriate algorithms and data structures, and using the > right tools.
I think that this is right. Most problems I see with development have 3 main roots in decreasing importance:
1. Not completely understanding the problem that is being solved 2. Not understanding the strengths and weaknesses of the tools being used. 3. 'Bricked-in' solutions. That is, building things in a way such that changes are extremely costly.
I think what you are saying is related mostly to 1 and maybe a little to do with 2. And understanding the problem is crucial. No tool is going to help you if you are solving the wrong problem.
The second issue has to do with misusing tools. I see a lot of hard-coded Java code for mapping from one thing to another. Java is perhaps the worst data-mapping language around. It's pretty good for building a mapping tool, but not for writing the mappings themselves. I also see people trying to use mapping tools to do general development which has different problems but ones that are just as painful, if not more. Before you start using a new tool you need to know what problems it's good at addressing.
It's the last issue that IMO is where tool choice can make a big difference. The more abstraction points that are baked into the language the less the designers of a systems are required to design them into the system. It's makes a big difference in the ability to adjust to change.
But ultimately, that is the least important issue. I think what you are trying to say (and I agree with you) is that a lot of people tend to invert the importance of these issues thinking that if they just get the right tool, everything would be better when really the issue is at a higher level. Tools are important, just not the most important part of development.
I think that it is by now conventional wisdom that Moore's Law has not run out of steam, but the physics are forcing hardware designers to go "wider, not faster". Massively-multi-core systems (on your lap, even) can most effectively be utilized by code whose design/implementation is less sensitive to race conditions. The functional-programming approach tends to provide that safety.
OOP began with Simula in the early 1960's and has only been mainstream for a handful of years (say, since 2000) so we're looking at roughly a 40-year transition from small-scale/niche usage (Norwegian Computing Center, Swedish Research Institute for National Defence, etc.) I'm confident that there were people who looked at those facts (or even at the development of Smalltalk at Xerox PARC) and said "That's fine for those exceptional circumstances, but I'm crankin' payroll and BOMP in COBOL, so why should I care?"
I see functional programming today as roughly equivalent to where OOP was when Smalltalk hit its stride in the 1980's. If I think I'll retire (or move out of development) within the next 10 years, maybe I don't care. If I hope to be around for a while (or don't mind being a little closer to the bleeding edge) then maybe I want to start looking at it.
Regarding the perception that it's too specialized, I'd recommend the presentation by Simon Peyton-Jones called Composing contracts: an adventure in financial engineering ( available at http://research.microsoft.com/~simonpj/Papers/financial-contracts/contracts-icfp.htm ) as the kind of thing that will catch the attention of the suits.
Finally, as someone who was there in the late 60's and 70's, I'd point out that the kind of code we're mostly writing today is radically different than the kind of thing we spent most of our time on back in the day. And I believe that this is a direct result of the increased power of our tools.
So putting all of the above in a pot and stirring with a stick, I believe that FP is going to become increasingly important and influential. I suspect that this will happen faster than the cycle experienced by OOP.
A flat message and all transfer of the themes are done for the stuffed is for temple. It is done for the production of the essaymama.com paper writing in the urgently followed items for the people it is done for the mutual ay of the hope for the humans. It is ensured for the price wicket of the people in the community.
