Both of independently came to the conclusion that mutli-threading in our conventional objection oriented languages is a bitch. Even in languages which are considered easier to program in (such as C#, Java and VB) the things you have to go through to setup a multi-threaded app are fairly painful. It will break the normal approach to VB coding. In a multi-threaded app, nothing kills you faster than shared, global, mutable state. The next thing that kills you is uncontrolled side-effects all over the place.
There are veteran C/C++ programmers who will tell you never to purse more than a 2 thread model in any of your programs. You should have one foreground interface thread, which keeps the user interface responsive and reporting to the user. You have one background worker thread which invisibly does all the processing work. The two synch periodically. The end user is notified when the job is done. This is how SQL Management Studio does business when you process SQL statements. Anything beyond this basic parallel model is risky. Its just too complicated to manage well, or so they say.
Unfortunately for these experts, Jason and I know that this 2 thread model is not going to cut it in the future. Many others have come to the same conclusion. Intel and AMD are going parallel in a major way. Everybody is going to walk that path with them. Quadcore is now ubiquitous and cheap. We even have quadcore laptops. Consumers and businesses are going to want software which exploits this power. They are not going to continue to accept slow running serial-chain single-threaded software that does not exploit the power of their nice processors. Mutli-threaded programmers will first enjoy competitive advantage. Eventually, they will obtain competitive exclusion. This won't happen over night, but it is in progress. We will get there.
This means a lot of your rank-in-file business programmers will be leaving the field soon. I see many failing to adapt now. I foresee most of these programmers never adapting. People are always leaving the programmer ranks for other careers. The fallout rate in programming is rather astounding. That rate increases massively when major technological shifts occur. That rate is going to accelerate in the years to come. As this process runs along, VB may become the new FoxPro.
So why get into Object Functional languages? Because it is easier to multi-thread these languages. Functional, higher order languages are naturally stateless. They heavily emphasize immutability of data within any scope. Once you set an identifier to a value, it cannot be changed. Side-effects must be tightly controlled in monads. For these reasons, NASA has little problem taking a 40,000KLOC program written in OCAML and smushing it across a cluster of 1,024 processors. Erlang is probably the most heavily clustered language in the history of the industry. It is a pure example of the functional paradigm. If you follow the natural rules of the road in these languages, you will windup with a naturally thread-safe app that does not require extensive mutexes and locking mechanisms. You can do a hell of a lot more than 2 threads worth in these languages, but you must accept the natural schema of these languages. You cannot fight the natural order of the language.
So which language do we choose? Do we use a pure language like Haskell, Miranda, ML, or Erlang? No. We would be absolutely fucking lost without our objects. We need OOPs, or all our patterns break. We need an impure Functional language which gives us the goods whilst still allowing us access to the goods of the Java JEE and the .NET BCL. This is a natural requirement and we have to have it.
So what impure choices give us Java JEE and .NET BCL? Well, there are two. F# is offered by Microsoft and will be a part of the Visual Studio 2010 package, which just went Beta. Scala is offered by the open source movement and the Swiss ETH. Martin Odersky is the big man on this project. It gives full access to the JEE. Supposedly, there is also a .NET version of Scala.
Now for the title track: What is the difference between F# and Scala?
F# is basically OCAML. F# is OCAML which has been ever-so-slightly adjusted such that it will fully support all of the intrinsic types and categories of the .NET framework. Some .NET elements (such as delegates) have no meaning or usefulness in a higher-ordered world of OCAML. If you want to pass a function pointer, there is no need for the machinery of a delegate. Just pass the function to another function. However, F# needs delegates so that it can smoothly interop with code written C# and VB.
OCAML is the Object-Oriented version of CAML, and it showed up for the first time in 1996. CAML (Categorical Abstract Machine Language) is the French version of ML, and it first appeared in 1985. ML is a Scottish invention which first appeared in 1973. ML stands for Metalanguage. The objective is to write down mathematics in a rather straight-forward way. That is the absolute idea.
F# is a language with a strong family legacy that rolls back to 1973. It is not really a new thing at all. It is just OCAML ported to run on .NET. This is good news and bad news. It means you have a pretty good formal spec. It means that you have a smattering of highly experienced users. It means that you have a bunch of free-floating source code on the web. It means that there are non-new, and well-done learning resources. See an OCAML example. Copy and paste it into Visual Studio. Run it. Watch it fly. It means that that one big Wallstreet hedge fund that uses OCAML can now move to Visual Studio. Don't laugh. That was a very serious reason for selecting OCAML. This long history has some negatives associated with it also. F# is a language which inherits some ponderous baggage.
OCAML does support some object orientation, but it all began with ML, which is not even slightly OOPish. I am not thrilled by the level of OOPs support in OCAML. OCAML is a lot more functional than Object Oriented. It is a lot more functional than imperative. It is not far from pure. For this reason, F# is more functional than OOPish. It is more functional than imperative. F# ain't that far from pure either. While far better looking than something hideous like Erlang, OCAML and F# are far from an easy syntax to pickup if you are C# or Java programmer. You won't have an easy outing if you go that route.
On the other hand, Scala is a truly new language. Scala begins with body frame of classic OOPS language, and brings the full-house of functional stunts into that OOPS housing. Don't think that Scala lacks functional powers. It has everything functional. Martin Odersky declared that his purpose was to find the perfect fusion of OOPS and high-ordered Functional programming. I think he did one hell of a job. Odersky had a second objective in mind. Ordersky wanted to create the successor language to Java. Scala compiles to Byte Code and can use any jar of Byte Code directly. Don't think for one second that this means that Scala inherited a lot of ponderous family baggage from Java. Rather, the objective was to drop all ponderous baggage, and get a fresh start from Greenfields.
Scala has influences, but it has no family baggage. It does not look much like Java, but it has Java influences all over the place. It lives in the Java VM, after all. Although you can use Java Jars, I seriously doubt Java can use Scala Jars, unless the public interface point is very carefully crafted.
There is another dimension which has to be considered, and that is Intended Scope.
Having studied F# to some extent, and read the many blogs about it written by MS Research, I think it is clear that Microsoft is offering F# as a DLL language. By that I mean they have little intention of advocating WPF, WinForm, WebForm, SilverLight or MVC clients written entirely F# code. Of course, it is entirely possible to do so... if you know how to write all the code--by hand--from scratch. Do not expect Visual Studio tools to help you in this endevour. I believe Microsoft envisions a limited career path for F# as a language you write advanced DLLs in. Perhaps DLLS that parallel process gigabytes of Data in short order.
A guy might even infer that Microsoft envisions a division of labor in which an art designer makes XAML code in something like Adobe Illustrator... er... Expression Blend. This process determins what the beast looks like. Then a C# programmer writes a skinny controller class that handles events by invoking F# code (with parameters) stored in an F# assembly. This F# code performs hardcore processing of computationally intensive OLAP, and does so in a multi-parallel fashion. The C# programmer catches the return results from this F# assembly call, and updates the fancy interface designed by the artist. M-V-C. View in XAML done by an artist. Controller in C# done by a line-of-business developer. Model done in F# by some hardcore math-geeks.
On the other hand, I do not believe Scala has a pre-defined, task-limited scope. I think that the creators of Scala would like you to use this language in any and all contexts. No limits on scope are intended. Already, David Pollack has whipped out a cool Web Framework called Lift. I hear a lot of interest in doing JavaFX inteface work with Scala. Of course, you can use it to write JAR files which parallel process gigabytes of Data for a Java front end... if you are good.
F# cannot (at this stage) serve as a general-purpose replacement to C# and VB. You may want it too, but I don't believe it will go there or do that. I personally would never want to code WPF app in F#.
Scala can and will serve as a general purpose replacement for any language you use. It will go there, and it will do that. I do want to code websites and rich WinForms (JavaFX) apps in this code.
In view of all these things, I made a decision that I didn't like F# and I did like Scala. I believe Scala represents a new advancement of the state of the art in programming languages. F# does not. It is a port of an older language that has been around since 1996.
There is another thing to be said for the persuasive powers of the two men behind these languages. Don Syme is the front man for F#. With apologies to Don, he strikes me as the purest of math-department geeks. Not quite the sort of guy I would trust or follow... or so it seems. On the other hand, Odersky strikes me as a language genius from the richest tree of language geniuses. His family tree leads back to Niklaus Wirth, from whom all good things come. Odersky hails from the ETH in Zurich, which is Wirth's department. Wirth sat on Odersky's Ph.D. committee. Ergo he is a student of Wirth's. Ergo, he is just exactly the sort of guy needed to bring about this kind of revolutionary change.
