RSSExperimental 'Functional' Language Emerges from Microsoft Research
By Scott M. Fulton, III | Published October 23, 2007, 4:12 PM
Are the C programming language and its object-oriented offspring - C++, C#, Objective-C - still well-suited to the requirements of multithreaded, network-oriented computing environments today? That's the question on the minds of engineers at Microsoft Research, whose latest programming language is today being officially moved off the back burner. The F# language has received the company's official blessing.
"I am a big fan of technology transfer between a research organization and a product development organization so that we can 'productize' the great research ideas and deliver to customers in a timely manner," pronounced Microsoft corporate vice president for the Developer Division, S. Somasegar, in a blog post last Wednesday. "This is one of the best things that has happened at Microsoft ever since we created Microsoft Research over 15 years ago. Here is another great example of technology transfer at work."
There is no "F" language - F# is a fairly new concept from the ground up. It's designed for the .NET Framework, so it can integrate directly into Windows and also so it can share a workspace in Visual Studio.
The language itself is based on a long-forgotten premise, one that had not only been discarded but literally kicked aside at the onset of object-oriented programming in the early 1980s: Every instruction is a mathematical expression. Its syntax is adapted to work somewhat like a more conventional lexicon, but the F# interpreter is built to reduce everything it processes to a fundamental value.
Because of this, F# is extremely different from IronPython or IronRuby, two of the so-called dynamically typed languages built for .NET's new Dynamic Language Runtime. For that matter, it's on the other side of the planet from PowerShell, which is a very dynamic and flexible language best suited for scripting everyday Windows tasks.
Instead, F# takes several steps back in language evolution, looking away from objects and de-emphasizing code modularization. It even brings back the old let statement first introduced to programming by Profs. Kemeny and Kurtz, the creators of BASIC and the men who first brought ALGOL-based procedural languages into the reach of ordinary human beings.
Having backtracked all that long way, F# finds itself the derivative of an old University of Edinburgh project called Standard ML. Like BASIC, it's a mathematical language, but it's more strictly structured. Mathematicians call this concept "functional language," though Microsoft has already misused that phrase in its explanation, as though it meant "capable of doing stuff." No, it means that every F# program defines a mathematical function that has any number of inputs and at least one discrete output. Thus, it is essentially what some of the first programming languages used to be.
This makes F# phraseology very different from what many Windows programmers have become accustomed to. Here's a fragment of an example from the most current F# distribution, that sets up and displays one of the common forms in a Windows form library:
let mnuiOpen =
new MenuItem("&Open...",
new EventHandler(fun _ _ ->
let d = new OpenFileDialog() in
d.InitialDirectory <- "c:\\";
d.Filter <- "txt files (*.txt)|*.txt|All files (*.*)|*.*";
d.FilterIndex <- 2;
d.RestoreDirectory <- true;
if d.ShowDialog() = DialogResult.OK then
match d.OpenFile() with
| null -> printf "Ooops... Could not read the file...\n"
| s ->
let r = new StreamReader(s) in
printf "The first line of the file is: %s!\n" (r.ReadLine());
s.Close();
),
Shortcut.CtrlO)
In a typical procedural language, you'd declare a set of variables for holding the contents of the parameters for this Open dialog box. You'd load those variables with default values, then you might pass the method for opening the box, and then invoke a new variable for trapping the user's response to that box.
But in F#, you express a dialog box the way you'd express a function. So you don't "declare" anything right up front; instead, you say there's a statically typed value (here called mnuiOpen) that represents the user's response. You state that first, not last. The parameters of the built-in MenuItem() function are themselves comprised of multiple instructions, because remember, all instructions in F# reduce to expressions, which have static values. The second parameter of that function is an event handler, which draws its result from the value of variable d.
Now, this is important, because d hasn't done anything yet. With a typical procedural language, you'd solve for d and then pass it along as a parameter. Here, you introduce d by way of explaining what d does, which is what makes this language functional rather than purely procedural.
As with internationally recognized mathematics, you introduce the symbol and then you explain it. Note all these components of d, which here take on the structure of the .NET OpenFileDialog() function. All these things are explained by way of introducing them as functionally intrinsic to the result.
After a whole lot of historical backtracking, F# takes several steps forward in a different direction, as though programming evolution all this time weren't driven by the search for objects or some kind of underlying, all-inclusive philosophy there, but by mathematics. F# is a statically typed language at its heart, which means it has something very much in common with C after all.
That direction is multithreading, which is something the Standard ML creators never considered. F# embraces a concept called asynchronous workflows, in which a thread is considered a workflow (not like a Microsoft Workflow Foundation concept) whose result is, like every other F# instruction, a discrete value. You create the thread by encapsulating it as a workflow whose result is represented by the static variable.
But the way that these workflows are cast, they are not immediately executed the way they would normally be in F#. Instead, they are cast as arguments to the method Async.Run, which triggers separate threads for them but does not await the result.
Asynchronous workflow is extremely important for F#, because now it has a way of forking off its functionality to Web services - which all take place asynchronously, and which aren't always reliable - without having to pause like a ping utility awaiting either a response or a timeout. It also gives F# an indirect, though solid, connection to all the other functionality on local and global networks alike, that are not written in F#, and should not have to be "interfaced" like in Microsoft's rapidly-more-ancient concept of DCOM.
"The somewhat mathematical slant of functional programming just seems naturally appealing to professionals whose primary domain is described with mathematical notation - domains such as financial, scientific and technical computing," Somasegar continued. "On top of the syntactic appeal, the strong type system yields the sort of guarantees which are often crucial in these domains, and enables a superb tooling experience through Visual Studio."
The F# compiler for .NET is available from this page. The interactive command line tool does not require Visual Studio, though the installer package does include VS extensions.
kinda old school LISP.... :))))
PHP and script folks will like it, others - skip it:)))
Score: 0
GOSUB!!
Score: 0
Finally... a rocking functional language that might work! If i am correct, functional languages are inherently multi threaded, which helps a lot in this modern age of multi core processors.
Awesome
Score: 0
This article reads like this is something new, but the linked page says it's been available since July 31st...
Score: 0
" There is no "F" language ..." well technically there is a programming language called "F" although not related to F#.
It's a subset of Fortran and was quite popular in academia. Most university libraries have various books on 'F' and apparently it still is used by quite a few people.
Score: 0
Anything that makes languages more responsive in compiling (real-time compilation like HTML) or more simplified to pick up, bravo.
We all did C64 basic:
10 let x=4
20 print x
30 end
Do we go back to that? No. But here I am 20 years later, and I get that.
I do yearn for simpler languages, even at the risk that they don't perform well. The truth is that every VS-language to date is overly complex.
Let's get programming back to the people. Otherwise, it's going to be those that have the time to figure out difficult languages (read: China, India) will continue with their lead.
Score: 0
it's going to china and india because they'll do it for less money ... period.
Score: 0
HTML is a markup language, not a programming language, and it certainly doesn't compile. Essentially it's a standardized document format.
Score: 0
I started with C64 BASIC and continue to do VB.Net. Sure, .Net can be very complicated, but only if you want it to. With VB you can turn on relaxed mode (option explicit and strict off, although not recommended). Your code above would be this:
Dim X = 4
MsgBox(X)
Thank god I don't have to write my own line numbers anymore.
Score: 0
"Asynchronous workflow is extremely important for F#, because now it has a way of forking off its functionality to Web services - which all take place asynchronously, and which aren't always reliable - without having to pause like a ping utility awaiting either a response or a timeout."
Maybe my brain isn't working but this doesn't sound right. Is this saying that F# has something special built in for accessing web service asynchronously? Because you can access a web service asynchronously meaning you offload your call to another thread without blocking but web services themselves are just HTTP calls which are synchronous and behave just like the ping utility.
Score: 0
There is nothing that requires HTTP calls to be synchronous, although you can implement them that way, it isn't required.
Score: 0
Can you explain that?
GET / HTTP/1.1
Host:localhost
HTTP/1.1 200 OK
Content-Length: 1234
Content-Type: text/html
You issue a command and have to await the response. I guess if you don't care about whether you get a 200 OK or 500 error message than you can bail but I'm pretty sure most servers would treat that as an abandoned session and cancel the call. Sure you could make a call, pickup a token and keep checking the status but now you've got a monitor thread spinning which you or your framework has to handle.
Score: 0
SWEET! From more in depth articles (not on BN obviously) F# looks like a very promising language with lots of room for expansion and modifiers. After compiling a few basic proggies, F# still needs to be tweaked a little but overall it looks good as a replacement for aging languages.
Just one more project for the weekend!
Score: 0