Bad news about F#

Just came across an article on InfoQ.com which I found disturbing. InfoQ.com is one of the very best sites on the web for programmers... any kind of programmer. They don't always get it right, and there are exotic opinions here and there, but they are usually pretty damn good and informative. Ergo, I take this negative piece seriously.

The pitch line goes like this: "F# was supposed to free us of the unchecked null. Alas not only does it not do that, it introduces several more kinds of null." Or so Mr. Jonathan Allen says.

Whaaaa... WTF? This was something my own evaluation of F# did not turn up. Since this is the first written piece of its kind, I take it that this is a fairly original discovery. Jonathan Allen explains that in F# you can have a:

1. NullReferenceException
2. A Nullable Structure which will throw an InvalidOperationException if you hit it
3. If you use an OptionType to handle problem one, you get two possible exceptions. Passing None to the OptionType will once again throw the InvalidOperationException later. If you pass Some(null) to the OptionType, you will get a NullReferenceExpcetion. Ergo this is not a way out. You only defer the error to a later moment.
4. You can nest OptionTypes within OptionTypes. Ergo there is not the possibility of a tripple null exception condition. You won't like that.

Allen indicates that this does not happen often when you use native (exclusive and specific) F# types. These are the OCaml baggage types I mentioned in a previous blog. These problems are specific to CLR/CLS/CTS datatypes.

Jonathan does not go on to spell out the implications. He presumes that you can grasp that for yourself, if you are a competent programmer. He doesn't want to say its big because some Schill will come along and say he is being childish and lazy. "Of course this is easy to handle..." or so they say.

You not only have to write the same old code to handle all scenarios, you must write new handlers to handle more scenarios. BANG! I said it.

Folks, the implications are staggering. This means F# is poorly adapted for life in the .NET ecosystem. Its very nature and structure make more and new types of problems possible which did not exit before. Use F# types and you are fine. Interop with CTS types, and now you have more possible errors.

I am still sure you can make use of F#. I am now sure it is extra work with extra gotchas. This extra effort with extra problems at the core CTS level almost automatically relegates F# to life as a niche language, used only when you have to use it. It will not be used as a general purpose replacement for C# or VB.NET. Just a few little potholes in the road of full CTS compatibility constitutes a pretty nasty fly in the ointment. Now we have to start thinking about using the dreaded Interop word.

I am interested in hearing a rebuttal from Don Syme. Perhaps there is an easy pattern function that can be called all the time to deal with these issues. Perhaps that won't be a performance shredder. Perhaps it can be dealt with.

I dunno. It seems that Mr. Allen has discovered one of those bad welding points we have been speculating about for two years now. For about two years now, experts on the .NET platform have been wondering how Microsoft planned to graft a Functional language into the OOPS ecosystem of .NET. We have known that the Functional paradigm is extremely different from the OOPs paradigm. We have suspected that it was going to be difficult to make oil and water mix.

Others have tried. There was a Haskell.NET once upon a time. Others have failed. Haskell.NET is basically a dead letter. Microsoft insisted that OCaml was the proper catalyst agent that would allow .NET OOPs and Functionalism to mix smoothly. As I stated once before, I am not all that impressed by the OOPs of OCaml. I suspected there would have to be some significant adjustments.

Many types of Null is not a good idea. As a certain Italian C# architect has said in many video PodCasts "There is something unpleasing about this code." Luca is currently at work on an Agent framework for F#.

You see... I told you so. Scala has the upper hand. It seems to me that Dr. Odersky has found a much more perfect blend of OOPS and Functionalism than OCaml. Odersky was honest when he said he would be using OCaml himself if he thought it was the perfect blend of OOPs and Functionalism. There are imperfections in the OOPS model of OCaml. The adjustments made to OCaml in the F# language were not quite adequate to make for perfectly smooth blending with the .NET CLR/CLS/CTS.

This is not good news for Microsoft. I hate to tell my buddies this--and I do have buddies in Redmond--but the way you start is the way you'll finished. When F# goes gold in Visual Studio 2010, that first experience with F# 2010 will be most programmers' golden first impression of the language. A few potholes with the CTS, just a few violations of expectation, and they will say "Ah screw it! I'll play with this toy some other day. It's not something I can use."

This is how things get relegated to the waste bin of history.

On the other hand, Scala does blend perfectly with the JEE... as far as I can tell. So far I have read no published complaints.

The Difference between F# and Scala

Recently, a friend of mine (Jason Yi) got interested the new Object-Functional paradigm shift. He got interested for much the same reasons that I got interested in it.

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.

Java programmers are just hog wild about AOP

Recently, a flaming post went up on the DZone.com website.  A Java fellow posted a blog in which he bluntly stated that he would much rather employ Java programmers than C# programmers.  The absolute point of the piece is that AOP is extremely popular in Javaland, and all Java programmers (young and old) are well versed in the paradigm.  Such cannot be said for the C# programmer.  C# programmers seem to think that AOP is for testing only.  We don't seem to understand the other mega-benefits of AOP.  For this reason you should hire Java guys, not C# guys

I've given this political statement consideration over the past several days, I am completely sure that this a further example of the ethnocentric and narrowly learned specialization of all programmers in our field.  You see, the Java guy clearly doesn't understand the deep strategy of C#.  Neither does he understand the deep strategy of Scala.  Neither does the C# programmer understand why AOP is totally essential to life in the Java ecosystem.  The C# programmer does not understand why a lack of events and delegates in Java would push the entire ecosystem towards AOP.

Let me tell you about it.

Since the dawn of time, the dream of programmers everywhere has been code reuse and modularity.  We want to stop writing the same code over and over again every time we start a project.  We want a nice library we can compose with.  Composition is a big fucking word in our profession.  It is the dream of the blue turtles.  We want to write just those little bits of app-specific logic our customers demand.  Composition and reuse are the absolute ideas driving most changes over the past 30 years of computer languages.

Simple OOPs is nothing more than an attempt to achieve composition and reuse.  In the days of Smalltalk, simple OOPS worked out fairly well.  Because of the weak typing system, simple objects did the trick fairly well.  It was easy to interchange BaseA object with ModifiedA object, or BaseA with BaseB, or ModifiedA with ModifiedB.  The weak and dynamic typing system just went along with it, and if it could work, the interpretor would make it work.  For this reason, composition was pretty dang easy in Smalltalk.  There was pretty good code reuse in Smalltalk.

The problem is that a lot of us hate interpretors and weak typing systems.  A lot of us out-right fear dynamic systems for their unpredictable behavior and their slowness.  Others hated the ugly and goofy looking interface of the Smalltalk virtual machine.  Ergo, Smalltalk was not widely adoped and it ultimately died.  It was always a niche thing which the Ubergeeks used.  It is now having an interesting undead afterlife in the form of Squeek, but Smalltalk is dead none the less.

In response to Smalltalk, a number of strongly typed and compiled OOPs languages were invented.  C++ and Object Pascal were two perfect examples of this movement.  The problem was that they were only half-assed OOPs languages.  They were also structured.  A lot of Dephi programmers programmed in flat structured Pascal and claimed to be object oriented.  Likewise, a lot of C++ programmers were really writing C code and claiming to be object oriented.  As you might imagine, this approach did little for Composition and Reuse.  Worse still, once the language is strongly typed, interchange of BaseA object with ModifiedA object, or BaseA with BaseB, or ModifiedA with ModifiedB is no longer possible.  The signature of a function or a method demands a specific type.

Next, Java came around with a simple language and simple OOPs and the notion that you should inject dependences in an AOP fashion.  In this approach, you pass everything by interface type or abstract class.  This loosens the type system enough so that interchange of BaseA object with ModifiedA object, or BaseA with BaseB, or ModifiedA with ModifiedB is possible... with in some limits.  IoC and DI were formalized in things like Spring, AspectJ, and Guice to make this even easier.  You get pretty good code reuse in this AOP approach to doing business.  Implicit within this success story is a clear cut admission that pure OOPs doesn't yeild composition and reuse when you are compiled and strongly typed.  You need to take an AOP approach, or you don't get composition and reuse at a good high level.  

At roughly the same time (a bit earlier) Delphi came around with the notion that you should have something greater than objects called components.  These should be wired together with delegates and events.  Delphi died.  Java won by default.  Delphi was reborn as .NET and C#.  Suddenly the battle was renewed.

Of all the things that have triggered the greatest number of flame-wars between Java and C# programmers over the past 8 years, a pure lack of understanding of the .NET Component is top of the list.  C# programmers know they have components.  Some are dimly aware of how they work.  Many of them have no ideal in the world that Java lacks components.  They don't understand that strategy and command patterns are built into the CLR as first class citizens.  Specifically, strategy=events and command=delegates.  [Some would rap my knuckles for making that hard fast association.  Bring it on.  You'll get knocked the fuck out.]  These first-class citizens of the .NET framework are the foundation of components and loosely coupled, modular, composable, reusable code framework that we enjoy in the .NET system.

Java programmers do not understand this.  Events, delegates, properties, full lexical closures, all these things work together to make AOP far less necessary in the .NET programmer's life than in the Java programmer's life.  Coversely, because you lack events, delegates, properties, full lexical closures in Java, you need AOP much more than we do.  We get good composition and reuse without AOP.  We get good simple code without AOP.  If you think your AOP code is clean, you should see our component code.  It is wired together and loosely coupled with Events and Delegates.

This is not to say that AOP is completely irrelevant to the C# programmer.  Many of us, especially me, are asking serious questions these days like:

1. How can we take advantage of some of the goodness of AOP?  

2. When should I select AOP rather than a component approach?  

3. What are the specific scenarios where AOP is preferable to writing a component?  

4. Can AOP improve certain approaches where components don't work so well?

5. If so how?

So far, there is a lot of debate about this topic among serious minded C# programmers.  We don't have a lot of clear-cut, indisputable design-wins and use-cases for AOP.  Logging application activies and errors is one winner.  Automatic unit testing of production code is another.  This is strong sign of the high value of components.  They only break down {with certainty} in a couple of scenarios.  Of course, we do not yet understand AOP as well as we will in 10 years time.  In that time we may have even more compelling use-cases for AOP.  Right now, we don't.

It should be noted in passing that several veteran polyglot programmers are rallying against AOP in the .NET world.  In particular, the gentileman scholar Ted Faison has written a super book called "Event-Based Programming:  Taking Events to the Limit".    I remember Ted well from my Delphi days.  He was a great Delphi programmer.  Like most of us, he moved with Anders to the .NET platform and C#.  I like him and respect him, so I read his book.

Although Mr. Faison doesn't say it bluntly, a careful consideration of what he says in this book boils down to the following: "All of you C# programers runing toward AOP are headed in the wrong direction.  Don't do AOP just because the Java guys do AOP.  Use the events and delegates in our systems to wire together components, and you will obtain better and looser coupling.  This will give you the best possible composition and reuse you can obtain today."  I reached a conclusion that mega-AOP, as it is practiced in Javaland, is a specific solution pattern, in a specific language, which lacks key attributes we have.  Ted Faison might not have actually said that bluntly in his book, but I achieved that realization from reading his book.

This conclusion becomes even more interesting when you consider the design goals of the Scala language.  For those who don't know about it, Scala is Java's replacement and successor. This is like Marcus Ulpius Nerva Traianus taking over for Marcus Cocceius Nerva.  It is the succession from a good emperor to a better one.  Martin Odersky is explicit in his design manifesto for Scala.  Two questions drive him:

1.  Can we provide better language support for component systems?  He wrote a nice paper and did a video about this subject.

2.  Can we find a perfect fusion of Object Oriented Programming and Functional Programming at the same time?

Dr. Odersky very delicately offers a tough critique of Java in Scala.  You don't actually have a delegate in Scala, but you don't need one.  You pass functions without any delegate machinery in any functional language.  You don't have interfaces in Scala, but you don't need them.  You are better served by Traits, which give you all of the advantages of Interfaces, Mixins, and Multiple inheretence.  You don't have to pass things by Trait or by abstract class in Scala.  Type Inference and fully-orbed Generics will get the job done for you.  This generic based polymorphism obviates the need for OOPs polymorphism.  All of this adds up to a system which can do serious components, composition and reuse.

But this Scala approach to the problem is not well understood by Java programmers.  This is where they are going to have a big problem adjusting to life in Scala.  As a proof consider this:  A Java programmer learning Scala posted up at the Scala-Lang.org site.  He asked the following question:  How do I use Guice in Scala?  Since he was a Java programmer who did not want to reinvent the wheel, the question is perfectly understandable.  One of the Scala team members on the site answered his question.  Paraphrasing, the team member answered that AOP is basically out of place in Scala.  You can use it.  It is not recommended.  It isn't the Scala way of doing things.  Scala uses components.  Scala achieves composition and reuse by loosely coupling components together.  You don't have to inject methods, objects or any dependency anymore.  Use a trait, or pass the function or class to the object.  The old problems are not a big deal anymore.  To get the juice out of Scala, you need to get the Guice out of Scala.

The Java guy seemed extremely disapointed that the Scala team did not appreciate the great value of AOP.  It was likewise, I am sure.

Excited about Scala

I am excited about Scala! Those of you who know me know that I am a career-long Micorosoft Developer. First with Borland tools, second with Microsoft tools. Delphi & Paradox gave me my first real taste of professional success late in 1994, but there has been plenty of VB and C# along the way. Ergo, it will suprise many of you to know that I am excited about Scala.

For those who don't know, Scala is an OOPS/Functional hybrid language which primarily focuses on the Java VM and J2EE framework. It does run under .NET, but good luck in finding tool other than Notepad to program with.

Speaking of tools, the primary reason I have not learned Scala already was the tool experience. I am not a fan of EMACS. I piss on VI. I detest Notepad. Don't show me a plain text editor and expect me to accept that as a development environment. I am Borland guy at heart. I expect and advanced IDE, powerful tools, and a great experience. Borland JBuilder shocked the Java world, and tools like Eclipse and Netbeans followed quickly. Borland guys want killer IDEs. Visual Studio wasn't always the most advanced environment. Microsoft was forced to compete on an entirely different level by Borland.

Sadly, until just yesterday, I just couldn't get any of the plugins for Eclipse, Netbeans or even IntelliJ to work correctly with my installation of the Java SDK, and my installation of Scala. Without a good development environment, I just would not get into the language.

Wonderfully enough, this all worked out last night. I noted that there was a new edition of a Scala plugin for the Eclispe environment provided directly by the Scala team. I grit my teeth as I began to think of another major disapointment. It took some effort to get it going under Windows 7, and this effort included installing the basic JRE on top of my already installed JSE.

With that done, I only need to change the the developer "Perspective" in Eclispe to Scala, and begin work. Marvelously, everything worked. I could create a new Scala project. I could create Scala classes. I could compile. I could run. I could get correct results. I could copy code fragments from tutorials into Scala text files, compile them, and execute them. They all worked, exactly as expected.

Believe it or not, this was precisely what I could not do before last night. Copying code directly from tutorial pages into the editor would produce all manner of strange errors. Most assured me that this was a consiquence of integration problems between the development environments and the Scala compiler. That turned out to be the case, but it was little comfort when I was chomping at the bit, ready to go. It reminded me of the early days of Visual Basic 1.0, which was nasty buggy.

So why the hell do I care about Scala? I have been looking around for the next big thing for some time. I am looking for pure technical merit. I don't give a fuck about fashion trends. I rarely trust the uber geeks. It is clear to me that Ruby on Rails was advocated by Adobe web artists who clearly did not understand binary data types. It is clear to me that Erlang is being advocated by a certain species of Uber Geek that wants to exclude the mass-majority of rank & file programmers from their secrete club. When I look for the next big thing, I am looking for something with lasting and enduring power. For a number of reasons, I think Scala could be that thing.

Why?

1. Multi-parallelism: We are coming into a new era where every machine is can execute 4 simultaneous threads on a minimum of 4 cores {laptops are stuck at 2 cores these days, but even this is changing}.  Also, Hyper-threading is making a comeback.  Four-core chips like the Intel Core i7 are hyper-threaded, meaning it can execute 8 simoltaneous threads. Apple is already shipping a PowerMac with a pair of i7 Xeon processors.  That box will execute 16 simoltaneous threads.  WOW!   Right now, everybody I know {particularly my local Visual Basic programmers} are living in a violent state of denial about the implications of these developments. They intend to go on programming in a single threaded execution mode forever... or until somebody runs them out of the industry. I guarentee you, they will get run out of the industry. We are going to have to start programming in parallel. Scala offers us Actors, which are the easiest method for doing parallel programming I have ever seen.
   
2. Brevity: Scala seems to be a very terse language. It is the most terse thing I have seen since Python. Unlike Python, it does not achieve that brevity by going dynamic, omitting all type references, or type declarations. This is very good. You can write less code and get type-safety also
3. Immutable Data: Scala is a functional language. With it comes a couple of features of functional programming with which I am completely enthralled by. The first is Immutable Data. Once assigned, a variable... er... identifier becomes immutable and cannot change again in scope... unless you explicitly declare it as mutable. Most Ruby and VB programmers would blanch at this and turn white as a sheet. These buggers often want to change the class types of variables at runtime, not just the value of the variable itself. This is dreadfully unsafe. It also increases your Cyclomatic complexity dramatically. Immutable data means safer, more predictable, more stable software. This is going to be a tough discipline for some to learn, but we have to get used to it. It is good.
4. Monads: One of the terms Functional Programmers have added to our lingo in the past two years is the term Side-Effects. Side Effects are any changes to the state of the system which an application might perform at run time. Printing a document is a side effect. Writing changes to a database is a side effect and can create other side effects. Changing the users display is a side effect and can have other side effects. It turns out that things like network IO are the sources of most failures & errors these days. When you print, you cannot know for sure that the network is fully functional. You cannot know the printer is on. You cannot know the printer is loaded with paper. You cannot know it has ink or toner. When you make a web request, you cannot know the target website is up and running. We trust these things will work on a daily basis, but sometimes they do not. Functional programers have decided all such side effects must be locked inside a class type called a Monad. A Monad explicitly declares what sort of side effect will be created, and an entirely different level of error handling is imposed. This is a marvelous thing. I love it.
5. Traits: Traits are basically implement interfaces. If I have a series of common methods (say Load or Save) which must be implemented in identical fashion for 4 or 5 different class prototypes, I can now tack on a trait which will contain these methods. All the code is implemented in one place. This promotes very dry coding. Also, you can type variables according to their traits, just as you can by Interface in Java or C#. This is truly a simple and brilliant idea. I wish we had it in C#.
6. Super-Generics: For those who don't know, .NET offers us a pretty good implementation of generic collections. We can also make our own generic methods and generic classes. Java has a pretty poor implementation of Generics. In either case, both languages are out-classed by Scala. Scala brings the full-house of type-parametrization found in functional languages. This is well beyond what we are used to in .NET.
7. Functions are objects: The great shock to all imperative programmers like myself comes when we discover that we can make a generic dictionary of functions, or generic stack of functions, and pass that data structure full of actual code-functions to another class as a parameter for the further processing of data. I am not talking about passing the results of one call to function in a data stack. I am talking about passing the function itself. The possibilities boggle the mind. I have seen some stunning things done with this feature, not the least of which is pretty slick compilers and interpreters.

There are many other things that intrigue me, not the least of which is the LIFT web framework. I am very excited about the notion of writing my first website in LIFT and deploying that WAR file to Glassfish or Tomcat. I think it should be damn interesting,