Why the CLR languages fail?

[Zed Becker]

Why do the languages running on the CLR (ironRuby, ironPython, ironScheme, ScalaCLR) do not get to live long enough in the sunshine, whereas same languages get embraced by the Java runtime, and live in the limelight?

Chas did a survey in 2012, which gave very negative results for clojureCLR, with 70% people having no motivation to even play with it, and almost no production use.

How can ClojureCLR be protected from dwindling?

[Rich Morin]

On Jun 5, 2013, at 23:55, Zed Becker wrote:
> Why do the languages running on the CLR (ironRuby, ironPython,

> ironScheme, ScalaCLR) not get to live long enough in the sunshine,

> whereas same languages get embraced by the Java runtime, and live
> in the limelight?

I have a theory for your consideration. Consider the case of (say)
MacRuby, which was sponsored by Apple for several years. It had a
great deal of good work done on it, mostly by Laurent Sansonetti.
However, despite earnest pleas by Laurent's manager, Jordan Hubbard,
only a few folks in the user community jumped in to lend a hand.

Basically, I think it's very hard for a company to jumpstart an open
source development effort, particularly if the company is seen as
being large, wealthy, etc. Too bad, really...

-r

--
http://www.cfcl.com/rdm Rich Morin
http://www.cfcl.com/rdm/resume r...@cfcl.com
http://www.cfcl.com/rdm/weblog +1 650-873-7841

Software system design, development, and documentation

[Alexandru Nedelcu]

On Thu, Jun 6, 2013 at 9:55 AM, Zed Becker <zed.b...@gmail.com> wrote:

Why do the languages running on the CLR (ironRuby, ironPython, ironScheme, ScalaCLR) do not get to live long enough in the sunshine, whereas same languages get embraced by the Java runtime, and live in the limelight?

N.B. - Not all is well on top of the JVM. Jython, the Python implementation, tends to die and get revived and then it dies again. I don't know the state of IronPython right now, but it was in much better shape when I last looked at it.

The JVM is more popular for other languages though. There are multiple issues at play here.

Language authors prefer the JVM as a target, as it's easier to bootstrap a new language on top of the JVM. The JVM as a target is much friendlier to other languages, compared to the CLR, in spite of the initial hype surrounding the CLR's multi-language capabilities. There's also the huge open-source Java ecosystem to blame. For everything you want to do, there's already a library that you can build on top of (Netty is a stellar example, being used all over the place). Also, many language authors would like to support both, but they lack the resources to do it, so they end up picking one and stick with it.

Then there's the audience. Unix has always been a true tower of Babel for programming languages (that's why it has a Shebang). And the JVM has and always had first-class support for Unix variants, including Linux, BSD and OS X. People that target Unix for deployments (web apps, mobile apps) or people that use Unix on their workstations accustomed to Unix toolchains, will always prefer tools that are first-class in Unix. Having true cross-platform support and not having to recompile is pretty sweet too.

Then there are also the Java developers that are fed up with Java, the programming language, but love the JVM, the tooling available and the Java ecosystem (such as myself).

So Unix is like a tower of Babel for programming languages, but the .NET ecosystem is the exact opposite. .NET developers that want to pick alternatives to C# have an uphill battle to do against the status quo, as .NET developers and companies tend to be pretty conservative. The uptake of F# has been abysmal compared to JRuby, even though F# is included in Visual Studio and classic ASP.NET is still more popular than ASP.NET MVC.

JRuby is an interesting case-study. It is popular because it's used as a deployment target for web applications (Rails runs well on top of it), quickly becoming the de-facto standard, as more and more people start realizing how awesome it is compared to Ruby MRI in a server-side environment. With each release, performance has been improved by leaps and bounds. So it won converts that normally live in the Ruby ecosystem and had no interest in Java or the JVM.

Also, JRuby is a community-driven project, sponsored by multiple companies involved in the Ruby ecosystem, born out of real necessities and that thrived because it was designed to fit well within the existing Ruby ecosystem. IronRuby, a project started by Microsoft for demoing the DLR library, never stood a chance to catch up with it.

--
Alexandru Nedelcu
https://bionicspirit.com

[Colin Fleming]

The JVM as a target is much friendlier to other languages, compared to the CLR, in spite of the initial hype surrounding the CLR's multi-language capabilities.

I'm not sure this is true, Don Syme has written several times about how difficult it would be to implement F# on the JVM - I believe tail recursion and not being able to define new intrinsic types (i.e. new primitives) are the sticking points. I think a lot of people believe that from a functionality point of view the CLR is better than the JVM - as far as I know it's not missing any functionality from the JVM and it has significant advantages (reified generics as well as the functionality mentioned above).

That said, I agree with most of what you say. But it's not just the deployment and UNIX toolchain, it's also the development OS. I don't run Windows nor do I want to, but if I don't the development tooling for .NET languages is terrible. Even if Mono were a respectable JVM competitor for deployment (and it may be, I hear it's pretty good these days) there is no decent environment for writing C# or F# on OSX. Which is a shame, C# is a much nicer language than Java. So although I love the look of F# I've never seriously played with it, which means I'll almost certainly never use it for any real work.

Cheers,

Colin

--
--
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
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Alexandru Nedelcu]

On Thu, Jun 6, 2013 at 12:47 PM, Colin Fleming <colin.ma...@gmail.com> wrote:

I'm not sure this is true, Don Syme has written several times about how difficult it would be to implement F# on the JVM - I believe tail recursion and not being able to define new intrinsic types (i.e. new primitives) are the sticking points.

Yes, both of these have been issues people had to confront on the JVM. However, for example tail-recursion in CLR not being used by C# meant that it went unoptimized and even broken on the 64bits CLR for years.

Also, tail-recursion is not such a big issue, because self-tail recursion is easy to optimize by generating a simple loop (Scala does it, Clojure does it) and more complicated cases require indeed usage of trampolines. Not to underestimate their importance, being a useful feature to model state-machines, however you can still work by means of trampolines (Clojure elegantly solves it with syntactic sugar and it's workable in Scala because of it's good type-system [1])

On the other hand, the lack of support for new primitives has been hurting language implementations, like JRuby. Note that both features have experimental implementations as part of OpenJDK and it's possible we'll see them in the JVM. Plus, why stop at tail-calls? There are many languages that can hardly be implemented on top of both .NET and the JVM - not having continuations support, useful for Scheme or Smalltalk is a PITA. Haskell wouldn't be possible in either, because of it's laziness by default. You also mentioned primitive types, but for example the CLR lacks a Union data type, so implementing lazy integers for example comes with a lot of overhead.

 

I think a lot of people believe that from a functionality point of view the CLR is better than the JVM - as far as I know it's not missing any functionality from the JVM and it has significant advantages (reified generics as well as the functionality mentioned above).

That's not true. It does have a couple of advantages (like the ones you mentioned), but that list is shrinking and the advantages that the JVM has are huge and the list gets bigger with each new release.

Reified generics are actually a PITA for new languages. Scala's generics are much more flexible, with a much better design than the ones in Java - you cannot implement Scala's type system on top of .NET's generics without cutting down on their features. Erasure is not bad per se and for the utility of reified generics, it really depends on what language you're talking about. Erasure has only been bad for Java, because Java's type system is too weak and because in Java the wildcards are used on the methods themselves, rather than at the class level, which has been a big mistake. Also, Scala's type system is much stronger, much more static and much more expressive. I never felt the need for reification in Scala. It even has the option of doing specialization for primitives, to avoid boxing/unboxing, as an optimization option. Haskell also implements generics by erasure.

Reified generics are bad for other languages if you need to workaround them. For dynamic languages it's somewhat a disaster. On the JVM the bytecode is pretty dynamic, except for when you need to work with primitives (for invoking operations optimized for primitives) or when you call a method, you need to know the interface it belongs to (something which changed in OpenJDK 7 with invokeDynamic). Otherwise you don't have static types in the actual bytecode (e.g. casting an object to something is just an assertion in the actual bytecode that you don't need). But with reified generics, suddenly you have more static typing you need to take care of and avoid.

When generating bytecode it's easier on the JVM. The final packages (Jars) are just Zip files containing .class files, with a text-based manifest. The .class files themselves contain the debugging symbols and those debugging symbols are part of the standard spec, whereas the format for the CLR was never a part of the ECMA standard, was private and for a long time Mono has been using their own format for those debugging symbols, as they had to slowly reverse-engineer whatever Microsoft was doing. Because Java libraries tend to use a lot of bytecode-generating routines, the tools available for that are amazing (like ASM), whereas on top of .NET things like System.Reflection.Emit takes care of only a subset, so the Mono people had to come up with their own alternatives (like Cecil). For the parsers, you can use mature libraries such as Antlr, at least for the initial prototype. Speaking of Antlr, it does have a C# generating backend, but it's a poor and badly maintained port.

The JVM is awesome in what optimizations can do at runtime. VMs have a tendency to be optimized for their primary languages. In C# methods are final by default, whereas in Java the methods are virtual by default. This seemingly small and insignificant issue meant that the JVM needs to optimize virtual method calls at runtime - so the JVM can inline such virtual method calls, while the CLR cannot. The C# compiler is where most optimizations happen, whereas more and more optimizations have been move in the JVM itself at runtime ... Scala code runs as fast as equivalent Java code, even though the compiler is much newer and immature. The JVM can do other runtime optimizations as well, based on actual profiling and heuristics. It can do escape analysis to eliminate locks, if it sees that a short-lived object doesn't escape its scope, then it can allocate it on the stack instead of the heap (as a result of Java not having the ability to define new stack-allocated values). If an optimization isn't performing well, then it has the ability to deoptimize that piece of code and try something else. InvokeDynamic from JDK 7 gives you the ability to override the normal method-dispatch resolution. So you don't need to know the interface of a method when calling it. And such dynamic calls get the same optimizations as normal virtual method calls. This reduces overhead for languages such as JRuby.

The JVM has been used a lot in a server-side context. This means long-running processes that generate junk and that must have near-realtime low latencies. This means a lot of effort has been made to build garbage collectors that cope with such workloads. As a result, you have the concurrent mark-sweep GC (CMS), the new G1 from JDK 7 or Azul's Pauseless GC (expensive, but amazing, or so I hear). Alternative languages (such a Scala, JRuby or Clojure) tend to generate a lot of short-lived junk. And JVM's garbage collectors can cope with it efficiently.

I can probably think of other stuff, but this email is already too long :-)

[1] http://blog.richdougherty.com/2009/04/tail-calls-tailrec-and-trampolines.html
[2] http://www.artima.com/lejava/articles/azul_pauseless_gc.html

[Alexandru Nedelcu]

Btw, I knew I forgot something important ... on the JVM, exceptions are used a lot by language designers to control flow (like for emulating continuations). Throwing an exception on the JVM is cheap. On the CLR on the other hand it's very expensive.

[David Pollak]

On Wed, Jun 5, 2013 at 11:55 PM, Zed Becker <zed.b...@gmail.com> wrote:

Why do the languages running on the CLR (ironRuby, ironPython, ironScheme, ScalaCLR)

FWIW -- Scala on the CLR has always been a Microsoft funding issue. When Martin's lab got a grant for ScalaCLR, it did the work. When the funding went away, the work stopped. There was never a large pull to Scala on the CLR and given F# on the CLR, there was never any need for Scala on the CLR.

 

do not get to live long enough in the sunshine, whereas same languages get embraced by the Java runtime, and live in the limelight?

Chas did a survey in 2012, which gave very negative results for clojureCLR, with 70% people having no motivation to even play with it, and almost no production use.

How can ClojureCLR be protected from dwindling?

--

--
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
---
You received this message because you are subscribed to the Google Groups "Clojure" group.
To unsubscribe from this group and stop receiving emails from it, send an email to clojure+u...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--

Telegram, Simply Beautiful CMS https://telegr.am

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[dmiller]

On Thursday, June 6, 2013 1:55:13 AM UTC-5, Zed Becker wrote:

Why do the languages running on the CLR (ironRuby, ironPython, ironScheme, ScalaCLR) do not get to live long enough in the sunshine, whereas same languages get embraced by the Java runtime, and live in the limelight? 

Many respondents have dealt with this question, in detail.   I can confirm that some of the CLR extras (structs, reified generics, ...)  complicate life for the language implementer, particularly in the area of interop.

Chas did a survey in 2012, which gave very negative results for clojureCLR, with 70% people having no motivation to even play with it, and almost no production use.

For me, the more interesting question is:

 

How can ClojureCLR be protected from dwindling?

1.  Send more fish.  :)

2.  Contribute.

We can't do much about the culture in the .Net world that impedes adoption of these languages , as discussed by other respondents.

The biggest impediment seems to be tooling. Progress is being made.  This year has seen a noticeable increase in the number of contributors. ClojureCLR is now also on Mono, more libs have been ported, everything is being made available on nuget, we have a good start in the leiningen space with lein-clr and nleiningen (both mentioned in a recent thread here), and there have been some updates on the Visual Studio plugin.

We just need more.

ClojureCLR will have an official 1.5 release any day now (it's already caught up to 1.5.1 on the master branch, I just haven't tagged an official release yet).

I'd like to see the work on lein-clr (which depends on ClojureJVM) moved into nleiningen (native ClojureCLR) and nlein extended to be more comprehensive.

The nrepl port needs to be completed so it can be incorporated into nlein, the VS plugin, maybe emacs.

And the the VS plugin needs continued refinement.

I am not surprised by the low numbers for ClojureCLR on the Clojure survey.  

I am pleased by the increase of interest and participation that I have been seeing.

And I'm really glad we didn't call it IronClojure. :)

-David

[Brandon Bloom]

Alexandru's analysis is spot on.

Here's the pithy IRC version I've used in the past: "C# has a better type system and compiler, so it doesn't need as good of a JIT. That's a problem for languages that aren't C#, especially dynamic ones."

There are lots of caveats, but that more or less covers it.

[Paul Dorman]

Hi all, I'm super tired, so apologies if this has already been covered, but I think portability is the main issue. Java is very portable, whereas the CLR is focused on a single platform.

Also, most of the innovations in the Clojure space have been built on top of the JVM. Until Clojure reaches critical mass the really interesting developments are going to be created by the Clojure community, for the Clojure community, and the simple fact is the the JVM is where it's at in this respect.

Paul

--

[James Ashley]

On Friday, June 7, 2013 6:45:43 AM UTC-5, Mike Chaliy wrote:

Visual Studio and all around it is almost the only point why people use CLR. If language does not have VS integration (or integration is basic) there is no point to restrict yourself to CLR and this makes people to go with JVM versions of language as this give more wider options for deployment.

That's the biggest reason, but there are also corporate ones.

My last job was centered around SharePoint. We desperately needed every advantage we could get our hands on to be more effective. Most of the developers were convinced that C# is the best programming language ever, but the boss was amenable to better options.

I left before the idea ever even got to the drawing board, but I still think that clojure.net would make sharepoint quite a bit less horrible.

Be that as it may: if you work in a MS-centric company, shifting to JVM clojure is iffy at best. OTOH, convincing people who've never used anything except C# that there are alternatives worth considering is quite an uphill battle. At least one friend over the years has gotten fed up at my suggestions and sarcastically suggested doing everything in Prolog.

[Raoul Duke]

> Be that as it may: if you work in a MS-centric company, shifting to JVM
> clojure is iffy at best. OTOH, convincing people who've never used anything
> except C# that there are alternatives worth considering is quite an uphill
> battle. At least one friend over the years has gotten fed up at my
> suggestions and sarcastically suggested doing everything in Prolog.

so sad. F# is one of the best languages out there.