Slashdot Mirror
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."
Have no fear then.
The headline "Microsoft May Back Off dynamic .NET Languages" would be better?
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.
catch (HumourFailureException e) { e.user.send("You, sir, are a humourless idiot."); }
Similes are like metaphors
A lot of people have asked for and received said trouble.
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.
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.
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:
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.
>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
+1 duck typing is awesome.
I'd bet, part of the problem the GP is griping about is really people forcing problems that aren't meant for ruby or python or php into a web application. If you have 1000's or even 100's of models, why do you need a web interface for all of it?
Ruby on rails (and in particular my personal favorite flavor hobo) makes for awesomely quick development for small - medium sized applications. I wouldn't use it for a behemoth application, unless said behemoth is really 100 medium sized problems that got stuck together for no good reason.
Also, I couldn't imagine trying to develop a website in c or c++ with having to worry about memory management and poor string support.
I am not in anyway affiliated with Max Cannon
Java is better than .Net in the following ways:
- Good timezone support (.Net is a mess) .Nets
- 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
- 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.
Eh. This isn't always what you want.
That's why you get a choice:
The default is unchecked for C# and checked for VB.
IBM's compiler does do tail call optimization (for self calling)
It's trivial for safe calling. CLR has a special instruction to permit cross-method tail calls (it even handles function pointers), which is crucial for getting languages such as ML or Scheme to work right.
Again, not that useful. Esp, since hotspot can compile objects down to stack-based if it wants
Practice shows that global escape analysis is nowhere near as good as programmer's knowledge about how things should be. Yes, HotSpot can theoretically optimize those things away completely, but in practice it often cannot do even trivial stuff, such as avoiding boxing overhead in many common scenarios.
J/Invoke, JNA both do this
Yeah, and it's a mess due to Java's poor type system. .NET can directly map to anything that can be described in C - it has structs with explicit layout control (this covers custom alignment and unions), unsigned integral types, portable pointer-sized integral types (IntPtr & UIntPtr), raw data pointers, and function pointers. With J/Invoke, you have to jump through various hoops to tell it how to map your data structures.
Do int's in scala work differently than ints in java?
The real question is - do classes work differently? Can you take any Scala class and reuse it in Java?
mySortFunc.BeginInvoke (array)
CLR delegates are actually more like magically created (by the runtime) instances of anonymous inner classes implementing callback interfaces. Their advantage is that they're implemented very efficiently by the runtime (effectively just a function pointer + a captured "this" pointer).
javax.tools.JavaCompiler
That's not the same thing. Reflection.Emit lets one emit bytecode (CIL) into a byte array - optionally with a higher-level helper API - and then have it compiled into a method, and have a delegate to it returned. JavaCompiler would be more akin to CodeDOM, but they are heavyweight solutions. Reflection.Emit is used for stuff where speed is of importance. For example, .NET regex engine can compile regexes to bytecode (which is then JIT-compiled to native code, same as any other bytecode) for greater efficiency.
That said, you can still generate Java classes on the fly in memory as well, so it's a draw here.
java.lang.annotation.Annotation
CLR allows annotations to be placed on more things than Java. For example, on method return type.
There's one other thing in CLR type system - type modifiers, modopt and modreq. Those are somewhat like annotations in that they let types be decorated with other types, with VM ignoring it, and specific compilers interpreting the decorations as they need. Unlike attributes/annotations, though, those things decorate types (and not methods/fields/classes - i.e. not declarations), in any context (including parameter & local declarations, type casts... anything). This is used by C++, for example, to encode "const" and "volatile" - something like "const int* volatile" in C++ would become "int modreq(IsConst)* modreq(IsVolatile)" in IL, where IsConst and IsVolatile are classes declared in System.Compiler.RuntimeServices namespace. Any other language that has const/volatile semantics similar to C/C++ can reuse those, and can parse the existing declarations in assemblies compiled by Visual C++.
The VM furthermore considers two types with different modifiers to be distinct for the purposes of signature ma