Things like macros, STM, and the general simplicy of Clojure are all major wins IMO. I've worked in both static languages (C, C++, C#) and dynamic langauges (Clojure, Python, JS), and I have to say I'm about 3x more productive in a dynamic language like Python than I am in C# (and yes, I know the .NET platform like the back of my hand). I'm about 2x more productive in Clojure than I am in Python.

And I really cannot over stress the power of macros. Almost half of Clojure is written in clojure, and half of that is written in macros. In C# and F# I find myself writing the same code over and over again. In Clojure I simply wrap all that up in a macro and then have the language write that boilerplate code for me.

The interop features of Clojure far surpass F# in my opinion. Look at reify, proxy, and defrecord, they really don't have a comparison in F#. In addition, in Clojure almost everything is a function. A few examples:

(map :name [{:name "John"} {:name "Jim"}])
=> ("John", "Jim")

This sort of "everything is a function" philosophy runs throughout the entire system.

To end off with, the most telling thing for me, is that after 2 years I still have never really said "wow, F# had this feature, why doesn't Clojure have it?". True F# has tailcalls, but Clojure has recur and lazy-seq, and I've never needed anything else.

<disclaimer> I wrote the Clojure on Python VM port, so I'm biased. </disclaimer>

By on 7/19/2012 7:37 AM ()

Can't deny the extreme flexibility of LISP-derived dynamic languages. You program against an abstract model of computation (the lambda calculus) and can work at the 'meta' (macro / code generation) and 'regular' levels all at once.

If you believe Gerald Sussman (MIT) then LISP is the future! See: []

I think you would do things differently in F# for re-use than in clojure. Excepting the most extreme cases, F# has reasonable features for structuring your code. Meta-level programming can be done with in-lining, computation expressions and quotations.

The new F# 'interop' feature is type providers - which is a very easy way of accessing external metadata (database schema, web services wsdl, etc.) and making it a part of your type system at coding time.

Personally, I always had trouble with LISP's inside-out syntax and too many brackets. F# is more fluent and I think the code is more easily understood by others.

Also, for large enterprises - worried about supportability, etc. - I can safely recommend F# because it comes with Visual Studio and is supported by Microsoft.

By on 7/21/2012 7:29 AM ()

The simple fact is that F# today is much better supported than either Clojure or Scala; and unless Oracle adopts either of the later two, this will be the case for a long time to come.

One very basic feature missing from the JVM is support for tail calls. For a functional language support for tail calls is essential.

I think Scala has been able to work around the lack of tail call support in the JVM but I don't know about Clojure.

I have worked with both .Net and the JVM and have found that .Net comes with more out of the box and you don't need as much community support as in the case of Java/JVM.

F# has been really innovative with Computational Workflows (async monad, etc.); Active Patterns; and now Type Providers.

By on 7/15/2012 5:53 AM ()

Personally I very much dislike Clojure - primarily for lack of static typing. In the untyped family there is Racket, a much, much better designed Lisp. With that being said, if you insist on using the JVM, have you tried Scala? Scala is not without its quirks (poor tail call support, language complexity), but at least it is statically typed. Its type system also has some advantage over F# in supporting more abstraction (higher kinds).

Side note: for community libraries for F#/.NET check out []

Another thought: is Java really that open-soure? OpenJDK is (and some other implementations are), Sun Java isn't - they seem to be in a similar relationship as Mono and .NET. I guess your argument would be that OpenJDK et al are more compatible and better established than Mono, but only time will tell how this will develop.

By on 7/13/2012 7:59 AM ()

Hi Anton,

I've never really used a dynamic language for large projects so, although is commonly accepted that for large systems static typing offers more reliability, I don't really know how much it can affect me. On the other hand, Clojure is supposed to be designed for those large systems despite being dynamic.

About Scala... I don't really like it. I can't see it as functional as F#/Clojure, plus its weird syntax and type system doesn't help either.

I think I'll go with F#, because I may be thinking too much too long term when nobody knows how the computer world will look like in 15 years.

Thanks a lot for passing by. Cheers!

By on 7/15/2012 3:25 AM ()

Hi Jacobo,

Given that this is a subjective thread, regarding the VM, I don't think F# is tied to Mono at all in the long run. Nor would I have doubts about Microsoft investing into .NET. In fact, the .NET has been historically much quicker to incorporate new features and ideas than the JVM, which has helped languages like F# come about and funneling the ideas behind them into other .NET languages. So all in all, the VM angle seems to fit better with .NET, at least in my opinion.

Community-wise, F# has a lot to "learn" from languages like Ruby, Scala or Clojure. My feeling is that the community is growing only slowly because recognition (of users and companies) is little or nothing, and Microsoft has consistently stumped on F# in favor of C#. I am not a big fan of keeping F# on the backburner, and to me the biggest obstacle to letting a larger F# community develop is Microsoft's messaging and attitude towards the language. This is their internal politics, but even that can't stop progress for long so I would bet that you will see a much larger F# community growing out as a result.

By on 7/11/2012 6:11 AM ()

Hi Adam and thanks for taking the time to answer.

I don't really doubt MS will stop investing in .Net for at least some time, and it certainly is a pretty advanced VM, which I love. But I want to have the possibility of running my code freely wherever I want, and in case MS drops support don't get stucked. This is provided by Mono right now, but it's also a less supported effort than the JVM, for example. If MS stated legally that it would open source their VM if they stop supporting it, I'd have no problem. The same way if Mono had a level of acceptance as that of the JVM.

Maybe I'm wondering too much about a distant future instead of using what I want to use right now, but I'd hate to get stucked on proprietary technology that limits where I can run my code.

Thanks a lot for sharing your opinion! Cheers!

By on 7/11/2012 8:22 AM ()

Hi Jacobo, Microsoft usually guarantees 10-20 years of product life-cycle support even after they drop a technology/language for good. For instance, J# (dropped around the end of 2006) is supported throughout 2015, I believe. Dropping .NET would certainly be at the longer end, and in that unlikely event open sourcing it would certainly make sense business-wise.

By on 7/12/2012 7:36 AM ()

Hi Adam,

I am more worried about the future of Mono than that of .Net, because as you say they support things for a long time. But if Mono stops keeping up I'd be stuck with Windows, something I wouldn't like.


By on 7/12/2012 11:34 AM ()
IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy
Built with WebSharper