OSNews

I guess that would depend on why they call it experimental.

Which makes Apple's use of ObjC as a superset of C fantastic for leveraging all of C combined with ObjC's object messaging model we all know with the ever expanding collection of frameworks under the Cocoa moniker.

It's a .Net language so you're really not close to machine language...

I know it's .NET, but I meant in structure; functional languages are closer to how many chips work, if I understand functional languages right.

(Then again, there are apparently some chips that can run MSIL directly, which further complicates the issue.)

>functional languages are closer to how many chips work, if I understand functional languages right.

Well, I'd say that your understanding is wrong: many chips are stateful: they contain registers, memory..

And even pure combinatorial circuits are not really 'functional': their state depends on the time..

functional languages are closer to how many chips work, if I understand functional languages right.

Well, then you certainly understand it wrong.

The difference is more or less how programs are organized. And I personally break languages into the following categories:

1. Chaos - e.g. assembly, binary, etc. where you are not required to have any real structure.
2. Procedural/Functional/Structured - organized by the processing of functions and data structures
3. Object Oriented - organized by processing objects through their inherent interfaces (methods).

You could probably break Procedural/Functional/Structured into two if you really wanted to - Functional/Procedural and Structured, where the difference is between being centered around functions and being centered around data structures. (Whether you use "Functional" or "Procedural" is dependent upon the language family you use - e.g. C family or ALGOL/Modula family.)

Functional and procedural are completely different. Procedural programs depend heavily on mutable state. Functional program may have no mutable state at all.

Functional and procedural are completely different. Procedural programs depend heavily on mutable state. Functional program may have no mutable state at all.

I guess you could make that argument too. It's still procedure (function) driven though. So it's kind of a half-state between Functional and Structured from that perspective.

It seems like programming in F# would me much closer to machine language and the 'on-silicon' processes than most normal programming languages, C included.

On the contrary #F is right farther away as high level language.

There is more information on F# at Ars Technica [ http://arstechnica.com/news.ars/post/20071023-microsoft-to-push-fun... }

F# isn't a reproduced Haskell, it's a reproduces OCaml. It began as a .NET'ized OCaml, and has been developed from that point on.

I've been playing with F# for over a year, even buying the "Foundations of F#" book (though the upcoming "Expert F#" book might be considered the more "official" F# book, as one of its authors is F# lead Don Syme (both are available at amazon.com). Very cool language.
Here's a couple relevant links:
http://research.microsoft.com/fsharp/fsharp.aspx
http://blogs.msdn.com/dsyme/default.aspx
http://www.fsharp.net/
http://fsharpnews.blogspot.com/
http://cs.hubfs.net/blogs/default.aspx

Microsoft has been using it internally (XBox Live makes use of it) and others have been using it, but it's remained a "research" language within Microsoft Research, so there hasn't been "official" support for it. I'm glad to see it being productized. I've read the various Microsoft blogs on this, and unfortunately F# won't be included in VS 2008 since that's too close to shipping (though, apparently there was some thought of doing just that). It hasn't been decided yet how the productized version of F# will be released.

You mentioned Standard ML, well at the time that F# was started (based on OCaml), SML.NET was also started (based on SML). But its development stagnated, and isn't anywhere near the maturity of F#.

As for Haskell, maybe Microsoft will prodcutize that someday. Microsoft Research somehow gained maintenance control of the Glaskow Haskell Compiler a few years ago, and Haskell guru Simon Peyton Jones works at MSR now.

My first thought was: Great, next we'll see the F#@$ extended specification...

All (well most) languages have their place.
You mentioned OCaml's advantage over F#.
F#'s advantage over OCaml is that F# code can seamlessly operate with that of any .NET language, as well as access the .NET Framework libraries (e.g. BCL, WinForms, WPF, DirectX, LINQ), and non-Framework .NET libraries such as XNA and the numerous 3rd-party .NET libs. One could also program SilverLight 1.1 applets with F# (and SilverLight is x-platform (Windows and Mac, Linux (via Moonlight); IE, Safari, and Firefox), so SilverLight F# code is x-platform as well).

F#'s other advantage is that once it's productized, it'll have major financial backing from a large, high-profile, non-niche company. Including F# in a future Visual Studio or a A "Visual F# Express", for example, could be huge.

Edited 2007-10-24 00:32

Not very sure about becoming a professional product.

It belongs to the Research section, at least for now, so it only has some acceptance from Microsoft, specially from the economical backup point of view.

Look at IronPython, yes, is fine and nice and etc, and backed up by Microsoft, but where is the industrial support or follow up?

IIRC, some scripting in Vista is done in IronPython.

This "industry" you're talking about runs C# and VB.NET. They don't know Python. With IronPython Microsoft tried to cater to the comp sci fresh-out-of-college people. IOW, it was a way to leverage the experience those college students had with scripting projects, while attracting them to the MS Mothership.

My impression is that IronPython is surrounded by a *load* of hype, if only for the fact that it meant Microsoft endorsing the poster child of Open Source programming languages, but IMO it's just a novelty. Then again, I'm biased towards Ruby (actually, anything that leans towards Lisp (or Prolog) and Smalltalk is bound to attract me), so I'm not the most trustworthy source of Python critique. Take my words with grains of 50/50 NaCl/KCl.


Edit: on a second thought, F# is probably targeting the academia as well. When I had AI classes, for instance, the computer was running Windows, but every time my professor had show us and run a piece of Prolog code, he'd SSH his Linux box upstairs and run it on GNU Prolog. I can easily imagine MS trying to recover some mindshare from the AI/functional programming academic community. Shared Source, IronPython, sponsoring teaching .NET and XNA in Games Design and Programming classes, and now F#... That sounds like a plan to me.

Edited 2007-10-24 01:06

Silverlight 1.1 has the ability not only to run compiled .NET code (produced by any .NET language), but also run textual source code of IronPython, IronRuby, JScript, and VBx. There's your IronPython "support and followup".

That said, IronPython isn't "productized" like C# and VB are. F# will be productized like C# and VB, so it'll get support akin to those languages rather than the Iron languages, I'm guessing (hoping).

Wrong, or missleading, at least.

IronPython, or IronRuby should have their own support and traceability. Mono, or Silverlight can be able to process IronPython code, just because of the produced intermediated code, but IronPython is not the target there!

Is the same as implying than JRuby or Jython are successfull because any JVM can execute them.

Besides, which is the current real support for Mono?

I think both of those could be easily replaced with "language of choice = cross-platform."

The language is not the implementation.

F# runs on Mono. Check your facts.

Good questions considering sharps on the piano are the least used and flats are more commonly used.

What would be really funny is E#, or B#

You seem to be interested in music. My operating system doesn't support standard music files types, but it plays songs if you enter notation. One voice, though. Here's a nice song.

"e"=eighth note
"et"=eighthnote triplet
"q"=quarter note


void EndTsk()
{
Sound(0);
Exit;
}

void Song()
{
Fs->end_task_cb=&EndTsk;
music_tempo=2.5;
while (TRUE) {
Play("eDEqFqFetEEFqDeCDeDEetCGF");
Play("eDEqFqFetEEFqDeCDeDEetCGF");
Play("eDCqDqEeAAetEEFetEDGetBDCqF");
Play("eDCqDqEeAAetEEFetEDGetBDCqF");
}
}

Song;

You're missing the point. It's not about syntax...you can do everything you outlined in any language. The point is that F# is a purely functional language...I'd highly recommend reading up on what makes a functional language...well, functional.

Yes, many here have gotten the impression that F# is strictly a "pure" functional language. It can be used that way, but like OCaml, it supports functional, imperative, and object oriented programming.

Besides that, even "purely functional" F# programs that make use of objects provided by other .NET assemblies inherit the non-functional nature of those assemblies (depending on what methods the F# program calls).