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

Re:Shit.

[Lunix Nutcase]

Have no fear then.

Inaccurate headline

[Anonymous Coward]

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

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: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

[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

[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.