Clojure and functional languages advantages over .NET

195 views
Skip to first unread message

Bojan Jovicic

unread,
Feb 9, 2011, 12:48:55 PM2/9/11
to Clojure
Dear all,
what are in your opinion 3 biggest advantages that Clojure and
functional languages have over .NET, with focus on LINQ?

E.g. I thought of set functions, but this is supported in LINQ.

Any help is more than welcome for this student research.

James Reeves

unread,
Feb 10, 2011, 1:18:56 PM2/10/11
to clo...@googlegroups.com
> what are in your opinion 3 biggest advantages that Clojure and
> functional languages have over .NET, with focus on LINQ?

Do you mean .NET or C#? There are several functional languages that
run on .NET, such as F#.

- James

Joost

unread,
Feb 10, 2011, 2:01:43 PM2/10/11
to Clojure
On Feb 9, 6:48 pm, Bojan Jovicic <bojan.jovi...@gmail.com> wrote:
> Dear all,
> what are in your opinion 3 biggest advantages that Clojure and
> functional languages have over .NET, with focus on LINQ?

.NET is not a language, it's a runtime with explicit multi-language
support. There's even a clojure implementation that runs on .NET.
There's also F#, which is Microsoft's functional language for .NET.
The JVM and .NET runtimes both support loads of languages. There are
several other multi-language runtimes in the works at the moment.
AFAICS "serious" hosted languages are all moving towards a split
between langugage and runtime. Comparing languages to runtimes is not
very useful at this point in time and the question will probably
become even more pointless in the future.

Never heard of LINQ until you mentioned it, but it appears to be a
general data querying library. That sort of thing is generally
implemented as on top of a language/runtime. Clojure/Java doesn't
currently have something like that as far as I know, (unless you
count JDBC and the Clojure-specific layers on top of it like the
interesting ClojureQL), though I may be wrong - there is a stupendous
amount of Java libraries and frameworks out there and most work with
Clojure if need be.

> E.g. I thought of set functions, but this is supported in LINQ.

Clojure has sets and related functions in the core language, ClojureQL
implements sets in a way that might be closer to what you're thinking
about.

Timothy Baldridge

unread,
Feb 10, 2011, 2:42:32 PM2/10/11
to clo...@googlegroups.com
I know talked a bit about this when you e-mailed me personally on the
subject, but perhaps I'll take another stab at it.

But back to the subject at hand of C# vs Clojure. For me the biggest
thing comes down to immutability and functions with zero side effects.
I tend to code very functionally when I write code in C#. Infact,
since learing F#, my code C# looks more and more like F# code.

In OOP and C# you'll see something like this allot (sadly):

public void WriteData()
{
_fileWriter.Write("foo");
}

Now, just looking at this function, what is _fileWriter? Where is it
assigned? If it's null in this function where the heck do I go to
figure out what's gone wrong? We haven't a clue. So now we have to
either put a null check in this routine, or specify somewhere in the
documentation "Call open file before you call WriteData() or this
program will bomb".

Instead, let's write this like a functional program should be written:

public static void WriteData(StreamWriter fileWriter)
{
fileWriter.Write("foo");
}

Ah! Now we know exactly what _fileWriter is, and if it's null, well
then we know exactly where to go. And it's very clear that we don't
need a null check, since why on earth would you pass a null in to
WriteData(StreamWriter) and expect it to do something?

Now let's throw multicore into the mix. On the second example we can
do whatever we want to fileWatcher (such as seeking) and not be
worried about messing up the data for other threads using this same
class.

All this to say. Functional languages such as F# and Clojure make this
sort of programming easier. And as time goes on C# is slowly shifting
more and more to functional programming Eric Lippert (one of the main
devs working on C#) has said that immutability is future of C#.

I hope this helps some.

Timothy

Paulo Pinto

unread,
Feb 10, 2011, 11:32:22 AM2/10/11
to Clojure
Hi,

I got the impression that you don't know .Net.

.Net is a VM similar to what the JVM offers, there are many functional
languages that
target .Net as well.

Microsoft's own functional language F#
Currently VB.Net and C# provide functional programming constructs
LINQ is actually an implementation of Monads
There is OCaml for .Net
There are efforts in place to target Scala to .Net
And many other functional languages, that I have omitted.

Oh lets not forget that there is Clojure being developed for .Net as
well.

So I suggest that you rethink the scope of your question.

--
Paulo

On Feb 9, 6:48 pm, Bojan Jovicic <bojan.jovi...@gmail.com> wrote:

Bojan Jovicic

unread,
Feb 10, 2011, 4:48:00 PM2/10/11
to Clojure
Dear all,
I wish to thank you for your answers.

I am sorry for confusion because of my generic questions. We are
learning Clojure at University, and are looking for some nice example
of integrating it with one ERP system that has .NET integration
capability, so my question was directed at getting more insight about
following:

1) What would be the potential reason to use functional languages
(Clojure, F#, ...) vs .NET (because this is the context of this ERP
integration mechanism) non-functional languages (C#) with LINQ (a
Monads implementation as Paulo pointed)?
2) Are there potential advantages of Clojure over F#?

Thank you all, once again :)

Timothy Baldridge

unread,
Feb 10, 2011, 5:01:57 PM2/10/11
to clo...@googlegroups.com
I think it comes down to the following:

1) STM, for many applications, STM is a major plus (F# doesn't have
STM currently)
2) The LISP syntax can be quite freeing once you learn it
3) Clojure is a dynamic language, unlike F# and C#

Now here's the kicker. Depending who you talk to, all of these can be
"cons" as well as "pros". Dr. Cliff Click and Rich Hickey have had
some rather friendly arguments over STM and its usefulness in large
applications.

The LISP syntax can be viewed as a bad thing. I for one struggle with
it from time to time. I personally haven't decided if I think the LISP
syntax is a pro or a con.

And the dynamicness of Clojure can be considered a bad thing
performance-wise. Many benchmarks will show Clojure trailing a bit
behind C# in pure number crunching performance.

So it goes down to using the tool that fits.

My parents built a house years ago that uses steel for all the
internal structure. The thing is rock solid, and if it got hit with a
tornado it would probably still be there. But you know what? Hanging a
mirror on the wall ends up being an hour long process because you have
to drill into a metal beam before hanging the picture. Is steel better
than wood? Ask 10 people and you'll get 12 answers. It's all in the
style of the project, and your goals.

Timothy

> --
> You received this message because you are subscribed to the Google
> Groups "Clojure" group.
> To post to this group, send email to clo...@googlegroups.com
> Note that posts from new members are moderated - please be patient with your first post.
> To unsubscribe from this group, send email to
> clojure+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/clojure?hl=en

--
“One of the main causes of the fall of the Roman Empire was
that–lacking zero–they had no way to indicate successful termination
of their C programs.”
(Robert Firth)

Joost

unread,
Feb 10, 2011, 5:52:48 PM2/10/11
to Clojure
Please note that I don't want to start a big argument either.

On Feb 10, 11:01 pm, Timothy Baldridge <tbaldri...@gmail.com> wrote:
> The LISP syntax can be viewed as a bad thing. I for one struggle with
> it from time to time. I personally haven't decided if I think the LISP
> syntax is a pro or a con.

I think this is fair. Lisp languages work for me, mostly because they
make stuff that seems "special" in other languages much more explicit
and hackable. YMMV.

> And the dynamicness of Clojure can be considered a bad thing
> performance-wise. Many benchmarks will show Clojure trailing a bit
> behind C# in pure number crunching performance.

Dynamic languages make *development* fast. At least compared to Java/C
style "static" languages. Even if you're working on a program where
performance really matters, the big gains are very probably only to be
found in about 20% of the code base (and I think I'm being very
generous here). For the other 80% dynamic vs static typing is a non-
issue. But in a static language, you're still paying the extra
development time for that 80% of code where it doesn't matter.

Again, YMMV, IMHO, bla bla bla
Joost.
Reply all
Reply to author
Forward
0 new messages