Microsoft May Back Off of .NET Languages

An anonymous reader writes "Though Microsoft had initially made a commitment to create versions of dynamic languages that are customized for .NET, recent reports make it clear that the company may be stepping back from this plan. Much early speculation on this change in focus comes from Jim Schementi, previously the program manager in charge of Microsoft's implementation of the Ruby software known as IronRuby. Schementi reports on his blog that the team dedicated to working on IronRuby has decreased to one employee. According to Schementi, his departure from the company came as Microsoft began to display a 'serious lack of commitment' to any .NETized dynamic languages, including IronRuby."

Comments

Getting screwed in both directions

[bbtom]

So, Oracle are suing Google and making the JVM a less viable platform.

And Microsoft are pulling back on resources for IronRuby.

Looks like it may finally be time for the LLVM to step up to the plate and provide an open source alternative. Here's hoping...

Re:Getting screwed in both directions

[pitdingo]

how is .net better than java?

Re:Getting screwed in both directions

[not already in use]

• Unsigned data types
• Checked arithmetic (on overflow, they throw an exception)
• Support for tail calls (for Lisp, F# and other functional languages)
• Value types, these are structs that are not wrapped in an object
• VM-level support for generics
• Platform-invoke allows developers to call native code without having to write any glue in C++ using JNI, it can all be done in the managed language.
• The Common Language Specification: a spec that set the rules for interoperability across programming languages (for example: the rules for public identifier casing, handling of int vs uint and so on).
• Delegates allow user to keep a reference to a method or an instance method and invoke it. The VM also can turn any delegate invocation into an asynchronous invocation, so you can turn any method into an async method, like this: mySortFunc.BeginInvoke (array)
• Support for dynamic code generation through the Reflection.Emit API.
• A database file format allows for efficient reading of the metadata from assemblies. It does not require decompression and the database format is suitable for lazy loading.
• Attributes were special objects that could annotate most elements in the virtual machine, you could annotate classes, methods, parameters, local variables, and at runtime the VM or the runtime could do interesting things with it.
• Unsafe code (pointers) to support C++, Cobol and Fortran compilers running on the CLI.
• Native support for talking to COM-based APIs. Although mostly Windows-specific, its used to talk to Mozilla, VirtualBox and OpenOffice APIs in Linux.
• Covariance and contravariance introduced with .NET 4 make even more generic cases a pleasure to use.
• 64-bit arrays (although part of the spec, only Mono implements this).

Re:Getting screwed in both directions

[not already in use]

I think the reason for this is that a lot of web programming isn't overly complex and the brevity of a dynamic language is an advantage in these cases because you can't code something up pretty quickly. Anyone writing any sort of really complex web app in a dynamically typed language is just asking for trouble.

Re:Getting screwed in both directions

[Bill_the_Engineer]

So, Oracle are suing Google and making the JVM a less viable platform.

What?

Oracle is suing Google for making a non-compatible VM call Dalvik that uses technology found in the JVM without paying a license. Since Google wasn't using JVM, how does Oracle's actions against Google make JVM less viable?

Looks like it may finally be time for the LLVM to step up to the plate and provide an open source alternative.

LLVM is a low level virtual machine used to optimize compiler operations and runtime linking. JVM is a high level virtual machine providing objects, garbage collection, and according to Oracle technology patented by Sun. From LLVM website:

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies. Despite its name, LLVM has little to do with traditional virtual machines, though it does provide helpful libraries that can be used to build them.

LLVM is not a drop in replacement for JVM.

Re:Getting screwed in both directions

[Lunix Nutcase]

It wouldn't be a drop-in replacement but there is no reason that a Java front-end couldn't be created and combined with the LLVM JIT compiler.

Re:Getting screwed in both directions

[Bill_the_Engineer]

Technically you are correct.

Except for the white elephant in the room which are these patents that Oracle owns and have tested in court already when a 2003 court settlement with Microsoft created a 10 year cross licensing agreement that allows Microsoft to develop CLR.

I'm not advocating Oracle's position, and I'm against most software patents.

I was asking how a lawsuit that doesn't affect any of the JVMs in existence, or any Java or other JVM implemented languages that run within them, make JVM less viable? I would actually think the lawsuit could make the JVM more viable since it strengthens the power of the consortium that defines the Java standard and its related technologies.

Re:Getting screwed in both directions

[CasperIV]

Wait? Someone likes java?

Re:Getting screwed in both directions

[infamous_blah]

Thank you for this, PInvoke is probably my biggest reason in prefering .Net (mainly C#) over Java.

You can do this in Java with Java Native Access (JNA). From the JNA site:

JNA provides Java programs easy access to native shared libraries (DLLs on Windows) without writing anything but Java code—no JNI or native code is required. This functionality is comparable to Windows' Platform/Invoke and Python's ctypes. Access is dynamic at runtime without code generation.

Re:Getting screwed in both directions

[Anonymous Coward]

I had to work on a large Ruby web app once. They had over 300,000 unit tests, totalling 6.5 million lines of code. That was just for their unit tests alone!

At first I thought that was pretty amazing, but after working with the unit tests for some time, it became painfully obvious that they were just repeatedly implementing the basic checks that would be performed by the compiler for a static language.

Perhaps 5% of the unit tests were actually testing the functionality of the software itself. The other 95% were merely ensuring that the developers hadn't made simple typos in their Ruby code, or checking that the code could handle data or objects of the wrong type, or checking that the types of variables didn't change unexpectedly, and so forth.

I soon left because of how utterly stupid it became. For each day of development, I would spend, say, an hour developing a chunk of code, and then spend seven hours writing unit tests. Had I been using a static, compiled language, I would've spent 7.5 hours writing code, 15 minutes writing some unit tests to test the actual functionality, and 15 more minutes compiling that code periodically. Yes, I would have been over 500% more productive by using a static, compiled language instead of Ruby.

Re:Getting screwed in both directions

[scot4875]

That's pretty much a wash, as "Controlled by Sun" isn't much better.

--Jeremy

Re:Getting screwed in both directions

[Chris Newton]

If static languages are better, why is the bulk of web development done with dynamic languages?

I don’t know how much of that is reality and how much is popular perception. In any case, here are some general trends in mainstream statically-typed languages and mainstream dynamically-typed languages today that might contribute to the popularity of the latter for web development:

• The dynamic languages do not require the extra compilation steps in a build process. This probably speeds up prototyping. A lot of the web development in dynamic languages is probably done by small businesses or start-ups, and that sort of culture places a lot of emphasis on rapid prototyping.
• The dynamic languages tend to have much easier basic text processing. Basics like string formatting and regular expression parsing are a horrendous chore in languages like C++, Java and C#, relative to the trivial one-liners widely available in “scripting” languages.
• The dynamic languages also tend to have built-in support for structured data like nested hashes and arrays, where again you need to jump through hoops in typical mainstream static languages today. That kind of structured data is widely useful for defining easy interchange formats between browser-side code and server-side code. For example, on a current project, we have standardised JSON data that is accessed using several different programming languages in different contexts. In JavaScript or Python, it’s a breeze. In Java, it’s a chore.
• Integrations of popular dynamic languages with popular web servers are widely available and easy to set up. Setting up a Java-based web application is the sort of thing people write whole books about, dropping the names of half a dozen different technologies along the way.
• Likewise, integrations of popular dynamic languages with popular database systems are widely available and easy to use.
• A lot of web development projects are, rightly or wrongly, not treated as critical software systems where bugs are unacceptable. Encountering an error at run-time and dumping the visitor to some sort of error page is often considered an acceptable response, and people seem to expect and tolerate this behaviour without quite the same level of loathing they reserve for “Your application has crashed” dialogs or blue screens of death.
• Perhaps most important of all, most web development software is small. More formal systems with static typing and well-specified interfaces probably have a better cost/benefit ratio on larger systems where it is harder for developers to see the big picture and more difficult to co-ordinate people working on different parts of a system without such tools.

I think these are more reflections of the languages in current use and their surrounding cultures, rather than inherent traits of static vs. dynamic typing, but if we’re talking about the state of the industry today, there doesn’t seem to be any practical distinction.

Re:Getting screwed in both directions

[Anonymous Coward]

>Checked arithmetic (on overflow, they throw an exception)
Eh. This isn't always what you want.

>Support for tail calls (for Lisp, F# and other functional languages)
IBM's compiler does do tail call optimization (for self calling)

>Value types, these are structs that are not wrapped in an object
Again, not that useful. Esp, since hotspot can compile objects down to stack-based if it wants

>Platform-invoke allows developers to call native code without having to write any glue in C++ using JNI, it can all be done in the managed language.
J/Invoke, JNA both do this

>The Common Language Specification: a spec that set the rules for interoperability across programming languages (for example: the rules for public identifier casing, handling of int vs uint and so on).
Do int's in scala work differently than ints in java?

>Delegates allow user to keep a reference to a method or an instance method and invoke it. The VM also can turn any delegate invocation into an asynchronous invocation, so you can turn any method into an async method, like this: mySortFunc.BeginInvoke (array)
java.lang.ref.Method.invoke and java.util.Runnable(and friends)

>Support for dynamic code generation through the Reflection.Emit API.
javax.tools.JavaCompiler

>A database file format allows for efficient reading of the metadata from assemblies. It does not require decompression and the database format is suitable for lazy loading.
Jar files do not have to be zipped

>Attributes were special objects that could annotate most elements in the virtual machine, you could annotate classes, methods, parameters, local variables, and at runtime the VM or the runtime could do interesting things with it.
java.lang.annotation.Annotation

>Unsafe code (pointers) to support C++, Cobol and Fortran compilers running on the CLI.
A bad idea. If you must use pointers, use an opaque interface like sun.misc.Unsafe (stores pointers as a long)

>Native support for talking to COM-based APIs. Although mostly Windows-specific, its used to talk to Mozilla, VirtualBox and OpenOffice APIs in Linux.
Win32 Specific. Apache jakarta has an implementation anyway

>Covariance and contravariance introduced with .NET 4 make even more generic cases a pleasure to use.
Java has covariant return types. Not sure why you'd want non-explicit contravariance or covariant parameters.

>64-bit arrays (although part of the spec, only Mono implements this).
Eh. If it's really a problem, use JNI/JNA or a DB

Stuff that java does that .net doesn't
  - Work well on non Windows OS's.
  - Work on non-x86
  - GPL'ed reference implementation

Re:Getting screwed in both directions

[mldi]

That's "Controlled by Oracle", which is far worse than "Controlled by Sun", at least for viability.

Re:Getting screwed in both directions

[cowdung]

Java is better than .Net in the following ways:

- Good timezone support (.Net is a mess)
- JDBC is a solid database library (unlike Ado.net)
- java.util.concurrent
- simpler, stabler language without a lot of needless features
- checked exceptions (better type checking)
- more libraries (from Sun, from apache, from jboss, spring, etc..)
- more options
- more mature
- platform independent
- defacto language standard
- G1 garbage collector and a bunch of other fancy GC options
- Camel case is not broken in Java
- Javadoc format much more readable that .Nets
- pointer compression in 64bit
- escape analysis and automatic allocation to the stack
- several open source implementations and several commercial versions
- integrates well with several high quality application servers (standardized app servers)

See.. I can play too.

Shit.

[AnonymousClown]

I've been hoping for COBOL.NET.

Re:Shit.

[Megane]

...and FORTRAN.NET and RPG.NET. Damn.

Re:Shit.

[Lunix Nutcase]

Have no fear then.

Using them?

[0racle]

Was anyone actually using them? We have Python and Perl scripts running on windows and always preferred ActivePython and ActivePerl.

Re:Using them?

[bbtom]

Yes. I have used IronRuby - it is pretty nice. I don't know much about the Windows platform, and it is really pretty useful to be able to write simple Ruby scripts that can interact with .NET stuff. Scripting languages running on top of the CLR (and JVM) is pretty damn useful for a wide variety of applications and situations.

Re:Using them?

[raddan]

In fact, it was this one feature that made me realy, really like .NET. I know that .NET is anathema around here, but I think most of that ire comes from people who have never tried it. I'm a longtime UNIX developer, and after I took the time to learn .NET, I was pretty much floored. A lot of thought went into the language, the runtime environment, and even the IDE-- and I generally hate IDEs. The fact that I could run C#.NET on Linux (Windows Forms included-- there's even a GTK# interface!) was just icing on the cake. What I used to be able to do in a week takes about a day in C#.

Microsoft constantly does this: make something incredibly cool and then fuck said product over. Despite being the most schizophrenic corporation out there, they still make money hand over fist. Baffling...

Inaccurate headline

[Anonymous Coward]

The headline "Microsoft May Back Off dynamic .NET Languages" would be better?

Harder than you think

[cracauer]

The truth of the matter is that it is very hard to support random other languages on VMs written for certain languages.

All these dynamic languages do one thing or another that puts a hole in your plan. Ruby with it's continuations is right up there but Python with "modify anything fundamental anytime" isn't much better. The native environment has a huge headstart.

We should all move to LLVM.

What Oracle v. Google tells us

[ciaran_o_riordan]

With Oracle attacking Google over Java patents...

One lesson to be drawn, as suggested by Miguel de Icaza,[4] is that people should move to Mono and C# because Microsoft's patent terms are better than Sun's.

On the other hand, one could draw the lesson that it's foolish to use languages / platforms controlled by companies that use patents aggressively.

Another point is that if Google had used IcedTea (the GPL'd version of Java), they never would have been at risk from Sun/Oracle's patents.

Re:IronRuby

[bbtom]

Simple: choice. Lots of people like Python, and lots of people like Ruby. Having choice is a good thing. Plus there are some libraries (not just Rails) that are Ruby only - including things that benefit .NET programmers like domain specific language tools like RSpec, Rake and so on. Some C# users have been known to use Rake on IronRuby as a lightweight alternative to NAnt, for instance.

Re:C#

[MightyYar]

I know, right? Whenever I use C# all of these unicorns and ponies keep popping into existence. It was literally created by the Lord Himself.

Can I come work as an astroturfer now?

Ignorance, mostly.

[Anonymous Coward]

You need to understand the history of web development to answer that question properly.

The earliest dynamic web sites were implemented mainly in C and C++ by software developers who practiced the craft first and foremost, and treated web development merely as a particular application of their software development skills.

Starting around 1996, however, things started to change. Many non-developers started getting involved with the web. Some of these people had absolutely no programming experience, and thus just couldn't handle C. They ended up using Perl instead, which was basically the only practical scripting language at the time, since it was significantly easier to use than C or C++. PHP soon arose from this group of developers, and followed its own path.

Given the amateurish origins and background of this community, there wasn't much emphasis put on security, reliability, quality, maintainability and proper language features like static typing. That's why web applications from that time period are poorly written, and full of bugs and security holes.

On the other hand, Java soon became widely adopted by business users at roughly the same time, and soon enough they started developing web applications using Java. Many of these developers were former C and C++ developers, rather than Perl developers. After ASP.NET was released, they were soon joined by C# and VB.NET developers. These applications, being written by professional developers, are often significantly better than what was produced by the amateurish PHP/Perl community.

By the mid-2000s, the Perl/PHP community soon welcomed Python and Ruby, since they were more sensible dynamic languages that addressed many of the issues with Perl and PHP. Microsoft, Sun and others tried to draw these developers over to their platform by offering dynamic language support for .NET or the JVM. That's where IronPython, IronRuby, Groovy, JRuby, Jython and other language implementations come into play.

Given the history of web development, dynamic languages became widely used mainly out of ignorance, and have remained widely used due to continuing ignorance. There's no technical argument in favor of dynamic languages. They're just used because their users and proponents often don't even know about how much better and easier static languages make the development of both small and large applications.

Re:Do Microsoft products use .NET?

[lena_10326]

Are there any Microsoft products of importance that are programmed with .NET?

If you search for a Microsoft job, most are working with C# and C++. I interviewed at Microsoft in the past and there appears to be an extreme preference among their programmers to use C# because the majority of Bing/MSN code is in C#. I think Microsoft lacked the commitment because the prototypical Microsoft developer isn't interested in Ruby or Python. Those languages come with the baggage of social stigma: rogue developer, "non-enterprise", web monkey, low pay, low performance, 1 man startups, and "only for prototypes". It was clear to me developers inside Microsoft prefer C#.

Re:Confusion likely in Programming sphere

[obijuanvaldez]

If there is any confusion, you are adding to it. Microsoft is not going to "give up developing .NET," they are simply trimming the teams that were developing CLR implementations of Ruby and Python for the .NET Framework. This probably means the end of the Microsoft implementations for those languages, but that is all. It is foolish to think that if those languages are no longer supported by Microsoft for the .NET Framework that Microsoft will just give up on .NET Framework entirely.