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

87 of 443 comments (clear)

  1. Getting screwed in both directions by bbtom · · Score: 4, Insightful

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

    --
    catch (HumourFailureException e) { e.user.send("You, sir, are a humourless idiot."); }
    1. Re:Getting screwed in both directions by odies · · Score: 2, Insightful

      >

      And Microsoft are pulling back on resources for IronRuby.

      That doesn't really say anything. There's still C#, Delphi .NET, Visual Basic .NET, and a ton of other languages. The headline is wrong - Microsoft isn't dropping .NET support, it's just lowering their support for dynamic languages. Static languages are better anyway.

      Also remember that Windows Mobile 7 will only have .NET apps, which is actually quite good, since .NET is actually a lot better than Java.

    2. Re:Getting screwed in both directions by pitdingo · · Score: 4, Funny

      how is .net better than java?

    3. Re:Getting screwed in both directions by psbrogna · · Score: 2, Interesting

      If static languages are better, why is the bulk of web development done with dynamic languages? I'm not picking a side, just interested in your response.

    4. Re:Getting screwed in both directions by not+already+in+use · · Score: 5, Informative
      • 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).
      --
      Similes are like metaphors
    5. Re:Getting screwed in both directions by not+already+in+use · · Score: 4, Insightful

      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.

      --
      Similes are like metaphors
    6. Re:Getting screwed in both directions by CAIMLAS · · Score: 2

      Regardless of which language picked, it's not going to be a perfect fix. For instance, perl + library bindings would likely fit the goals of many .NET projects, as well as many java projects. And there's python as well, which has similar if not greater applicability. Both of which are very stable and well developed.

      I also have to wonder how the lack of IronRuby makes .NET any less viable. Could someone else not develop IronRuby? I see no reason why not, as I believe the same has been done for perl, python, etc. for .NET, outside of Microsoft. I doubt MS wants or needs the burden of supporting Ruby, anyway. .NET is, IMO, the best thing Microsoft has come out with in some time. There are toolkits similar to it, but for what can be done w/ .NET vs. other languages in a similar amount of time is simply incredible. The fact that the code is all mostly architecture portable (provided there's a CLR interpreter for it) is pretty cool, too.

      --
      ~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
    7. Re:Getting screwed in both directions by Bill_the_Engineer · · Score: 4, Insightful

      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.

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    8. Re:Getting screwed in both directions by Lunix+Nutcase · · Score: 4, Insightful

      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.

    9. Re:Getting screwed in both directions by beelsebob · · Score: 2, Insightful

      The usual reason given is that it saves on the write/compile/run cycle taking up your time. In practice, it's a pretty crappy reason though.

    10. Re:Getting screwed in both directions by Ironhandx · · Score: 3, Informative

      A lot of people have asked for and received said trouble.

    11. Re:Getting screwed in both directions by I!heartU · · Score: 2, Insightful

      ... Value types, these are structs that are not wrapped in an object
      yeah these can get "fun" with auto boxing and properties

      ... 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.
      no support on the phone for this

      ... Unsafe code (pointers) to support C++, Cobol and Fortran compilers running on the CLI
      not on the phone eaither

      .. Native support for talking to COM-based APIs. Although mostly Windows-specific, its used to talk to Mozilla, VirtualBox and OpenOffice APIs in Linux.
      not on the phone

      ... Covariance and contravariance introduced with .NET 4 make even more generic cases a pleasure to use.
      sorta nice but you don't get the cut and paste power of c++ templates. Also the phone is locked at some bastardized version of 3.. you don't get many of the 4 features. This may possibly change in the future.

      Another benefit of for is they've made a dynamic invocation system, so at runtime you can intercept function lookups, which will be pretty nifty for making scripting languages. Again the phone is lacking this atm.

    12. Re:Getting screwed in both directions by Bill_the_Engineer · · Score: 4, Interesting

      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.

      --
      These comments are my own and do not necessarily reflect the views or opinions of my employer or colleagues...
    13. Re:Getting screwed in both directions by bonch · · Score: 2, Informative

      - Controlled by Microsoft

    14. Re:Getting screwed in both directions by CasperIV · · Score: 4, Funny

      Wait? Someone likes java?

    15. Re:Getting screwed in both directions by rantomaniac · · Score: 2, Informative

      LLVM really isn't comparable to JVM and CLR. It's a compiler toolchain for generating optimized code ahead of time. It's really slow, but it generates optimized code. It provides no object model, unified exception handling, memory management, it's really just a tool, not a platform.

    16. Re:Getting screwed in both directions by Mongoose+Disciple · · Score: 2, Insightful

      how is .net better than java?

      In short, .NET is the Firefox to Java's IE 6.

      At one point, .NET was basically just a poor copy of Java -- but then it kept adding features and getting better while once-great Java essentially stagnated.

    17. Re:Getting screwed in both directions by 19thNervousBreakdown · · Score: 3, Insightful

      Because there aren't a lot of good interfaces for statically-typed language to web development. Believe me, if I didn't have to rewrite half the world to write web apps in C++ with a good Apache interface, I would do it in a heartbeat.

      That said, don't forget that a whole lot of development is done in ASP.NET now. It's changing.

      --
      <xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
    18. Re:Getting screwed in both directions by infamous_blah · · Score: 5, Informative

      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.

    19. Re:Getting screwed in both directions by Anonymous Coward · · Score: 5, Interesting

      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.

    20. Re:Getting screwed in both directions by scot4875 · · Score: 5, Insightful

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

      --Jeremy

      --
      Jesus was a liberal
    21. Re:Getting screwed in both directions by ratboy666 · · Score: 2, Insightful

      Positive things Java has over .Net:

      - Supported on Unix, Linux, Windows, z/OS, including AIX, HP-UX and Solaris.
      - Supported on Blackberry, and other hand-held devices.

      And, no, Rotor doesn't really cut it for support. For some limited uses, Mono on Linux may be usable, but .Net has very little, if any, penetration into z/OS, AIX, HP-UX and Solaris.

      So, it's fairly reasonable to not bother supporting "ultra-portable" programming. After all, if its single-platform, just build it there to begin with. Just like the iOS platform.

      As developers go, celebrate, because this de-emphasis just increased the value of your skills.

      As to the feature comparison of the Java vs. .Net run-time -- sure, "unsafe pointers" would have been useful to me. I wrote a COBOL-85 to JVM compiler, and the biggest performance issue is that data can, and often does, overlap in COBOL. Note that COBOL-85 doesn't have pointers, just redeclaration. This forces "interpreted" retyped access -- my compiler isn't smart enough to know when an overlap can happen. However, the primary target platforms are AIX and Solaris, so the feature remains... elusive.

      I am curious about your claim for "tail call support". Mostly, compilers are smart enough to replace a pure tail call with a simple transfer, and the run-time doesn't have to be aware. If the optimization is contemplated, there cannot be any partial results needed, and this must be maintained through the entire recursive sequence (direct tail call, or through another function). How does the run-time itself assist with this?

      --
      Just another "Cubible(sic) Joe" 2 17 3061
    22. Re:Getting screwed in both directions by Chris+Newton · · Score: 5, Informative

      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.

    23. Re:Getting screwed in both directions by Anonymous Coward · · Score: 4, Informative

      >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

    24. Re:Getting screwed in both directions by mldi · · Score: 4, Insightful

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

      --
      If you aren't suspicious of your government's actions, you aren't doing your job as a responsible citizen.
    25. Re:Getting screwed in both directions by Gr8Apes · · Score: 2, Informative

      • VM-level support for generics

      Hmm, yep, except there is no run time checking for type safety. You can merrily pass any (pointer referenced) object through any number of function calls and not throw any exceptions. All that's required is a little reflection.

      • Unsafe code (pointers) to support C++, Cobol and Fortran compilers running on the CLI.

      And this is the reason there is no type safety - because in the VM, LCD forces this upon you.

      • 64-bit arrays (although part of the spec, only Mono implements this).

      And there are features in the spec that MS doesn't support after 4 major versions? Say it isn't so!

      Then there are .NET collections which are .... basic at best. The concurrency toolset - much better alternatives in JDK5 onward. Dynamic code generation is also available (BCEL).

      And then there's the documentation. I never thought I'd actually think highly of Javadocs, but a nice 9 month stint through MS's documentation made me pine for the relatively concise and accurate Javadocs.

      --
      The cesspool just got a check and balance.
    26. Re:Getting screwed in both directions by FrangoAssado · · Score: 2, Insightful

      I am curious about your claim for "tail call support". Mostly, compilers are smart enough to replace a pure tail call with a simple transfer, and the run-time doesn't have to be aware. If the optimization is contemplated, there cannot be any partial results needed, and this must be maintained through the entire recursive sequence (direct tail call, or through another function). How does the run-time itself assist with this?

      I'm guessing that if the transformation (from a tail call to a branch) is done by the compiler, then the generated bytecode loses nice properties used by the checker to ensure it's well formed. If you do it like CLR (with a "tail" modifier to a call), the checker can verify it's a simple method call (and not a branch to some place outside the current method, which might or might not be valid) and then the JIT, seeing the "tail" marker, ensures the proper semantics for the tail call (stack doesn't grow, etc.).

      There might be other reasons, like performance: it's very likely that the JIT can do a much better job at optimizing a tail call (when it knows it's a tail call) than optimizing the tail call bytecode generated by the bytecode compiler.

    27. Re:Getting screwed in both directions by Touvan · · Score: 2, Interesting

      That's why I once held hope for Adobe's Actionscript 3.0 - it promised static (I read lower level) language support with the richness of ECMAScript (JavaScript) - but they seem to have implemented their static class system on top of ECMAScript underpinnings, without addressing the shortcomings of their dynamic runtime (it's still crazy hard to debug dynamic code written in AS3, and it's slow). So we ended up with all the bondage and discipline of a static language, without any of the performance benefit. I guess that's par for the course for Adobe.

      Anyway, I'd still love to see a language like that - one that provides all the lower level, bare metal features of a language like C, with the higher level runtime sweetness of JavaScript (one for performance critical libraries, the other for tying it together).

    28. Re:Getting screwed in both directions by gutnor · · Score: 2, Insightful
      No no no.

      .Net is IE and Java is Netscape. At some point, IE was better than Netscape and kept improving until Netscape died. Only after that it was abandoned.
      Java like Netscape run on multi-platform, IE the MS-only solution that MS put all its money on improving until it beats the competition.
      Microsoft cannot really uses its monopole to kill java, I hope Oracle does not do it for them - or at least does it quick so we can all work on an alternative.

    29. Re:Getting screwed in both directions by ultranova · · Score: 2, Informative

      Value types, these are structs that are not wrapped in an object

      Is that a strange name for a tuple?

      Support for dynamic code generation through the Reflection.Emit API.

      Technically speaking, you can create new Java classes at runtime by defining them in a byte array, there's just no API for creating those byte arrays from a parse tree.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    30. Re:Getting screwed in both directions by cowdung · · Score: 4, Informative

      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.

    31. Re:Getting screwed in both directions by Unequivocal · · Score: 2, Insightful

      Last I checked there are a pile of python and ruby websites out there doing fairly complex things -- are they all misguided? I obviously have an opinion, but I'm not trying to flamebait you - I'm actually curious what you think of that market segment.

    32. Re:Getting screwed in both directions by SplashMyBandit · · Score: 2, Informative

      You forgot to mention: .... and Android, and anywhere with a C compiler (so GCJ runs).

    33. Re:Getting screwed in both directions by lgw · · Score: 3, Interesting

      Value types, these are structs that are not wrapped in an object

      Is that a strange name for a tuple?

      Are Java tuples passed by value (I haven't seen them)? Certianly, "tuple" is an odd name for a struct! Of course, it's far odder that C++0x is adding "tuples", which seem indistinguishable from structs. Is there some buzzword compliance thing here?

      --
      Socialism: a lie told by totalitarians and believed by fools.
    34. Re:Getting screwed in both directions by lgw · · Score: 2, Interesting

      Okay, so how does one do it right? Because I remember having the same problem in Python, and suspect it haunts all the dynamic languages - after all, the type is still there, even if the language pretends otherwise

      In Python I prefer to put all the type checking in the function itself, not the unit testing. It's much more self-documenting that way. But I won't claim that's the one true way, not enough experience with Python.

      What I've never understood is why "duct typed" languages can't be static - if an object assigned to a given variable must support some operation, why isn't it possible to express this in code and have the compiler check it?

      C++0x is trying to do this with the new use of the "auto" keyword. I like the concept: you can tell the compiler to deduce the type on any variable you're initializing with the result of a function call. I can't wait to see how that works in actual production code.

      --
      Socialism: a lie told by totalitarians and believed by fools.
    35. Re:Getting screwed in both directions by Anonymous Coward · · Score: 3, Insightful

      No. Think again. Its the language.

      Unit Tests are there to detect developer errors, not language errors but the more errors the language allows the developer to make, the more Unit Tests you need. GPs conclusion is correct.

    36. Re:Getting screwed in both directions by shutdown+-p+now · · Score: 3, Informative

      Eh. This isn't always what you want.

      That's why you get a choice:

      int x = int.Max;
      int y = unchecked(x + 1); // int.Min
      int z = checked(x + 1); // OverflowException

      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

    37. Re:Getting screwed in both directions by shutdown+-p+now · · Score: 2, Informative

      JDBC is a solid database library (unlike Ado.net)

      JDBC has API that is horribly designed. One only needs to look at Statement and PreparedStatement - where one derives from the other, but they actually work very differently. Can you explain what the inherited PreparedStatement#execute(string) is supposed to do?

      java.util.concurrent

      TPL and PLINQ (and Java doesn't even have anything as high-level as the latter).

      simpler, stabler language without a lot of needless features

      That one is purely subjective. On one hand, a lot of people seem to want some features for Java that have been in C# for ages (such as properties or lambdas). On the other hand, another lot claim that e.g. generics are "needless", and I recall that before 1.5 that same lot also claimed that first-class enums are "needless"...

      checked exceptions (better type checking)
      more libraries (from Sun, from apache, from jboss, spring, etc..)

      I love how this goes together. Maybe you should go tell Spring guys about the wonders of checked exceptions...

      defacto language standard

      As opposed to an ISO standard?

      G1 garbage collector and a bunch of other fancy GC options

      Matched in .NET 4.

      Camel case is not broken in Java

      Define "broken", and provide references as to why your definition is more correct. Or else admit that it is another subjective preference on the order of "how many spaces in a tab".

      Javadoc format much more readable that .Nets

      I'll grant you that, though it requires a separate special parser. For C# and VB doc-comments, the compiler just extracts them as-is into an .xml file alongside the compiled .exe/.dll. If you use any custom XML elements, they will be extracted as well. Then you can use your own tools to process the .xml file as you see fit - and they don't need to be just document generators...

      escape analysis and automatic allocation to the stack

      Largely unneeded in .NET due to presence of value types in the type system, which are allocated inline all the time (as opposed to escape analysis, which still gets things wrong more often than not).

    38. Re:Getting screwed in both directions by Kaz+Kylheku · · Score: 2, Insightful

      There are many answers from different angles, but one is this: you were using an immature dynamic language with no compiler. The limitations of Ruby don't represent the state of the art in dynamic languages. Static languages with declarations also don't represent the state of the art.

      Modern languages, whether static or dynamic, don't have mandatory declarations, and rely on type inference.

      The difference between the two is that the static language disallows the execution certain programs which are allowed to proceed the dynamic language (but the dynamic language can still flag those programs).

  2. Shit. by AnonymousClown · · Score: 5, Funny

    I've been hoping for COBOL.NET.

    --
    RIP America

    July 4, 1776 - September 11, 2001

    1. Re:Shit. by Megane · · Score: 5, Funny

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

      --
      #naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
    2. Re:Shit. by Lunix+Nutcase · · Score: 5, Informative
    3. Re:Shit. by Lunix+Nutcase · · Score: 2, Informative

      ...and FORTRAN.NET

      Here you go. Though it's probably about 10 years old by this point considering you can find a codeproject page about it from 2001.

    4. Re:Shit. by blair1q · · Score: 2, Informative

      BrainFuck.Net FTW.

      You're welcome.

  3. Using them? by 0racle · · Score: 4, Insightful

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

    --
    "I use a Mac because I'm just better than you are."
    1. Re:Using them? by bbtom · · Score: 5, Informative

      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."); }
    2. Re:Using them? by bbtom · · Score: 2, Informative

      Yes, you can build DLLs and EXEs from IronRuby projects. I haven't done so - I just use it as an interpreted scripting language and a familiar REPL when on the Windows platform - but I've heard it is possible to do so.

      On JRuby - which I am more familiar with - you get both an interactive runtime and a compiler (jrubyc) which can turn Ruby into Java .class files.

      --
      catch (HumourFailureException e) { e.user.send("You, sir, are a humourless idiot."); }
    3. Re:Using them? by raddan · · Score: 4, Interesting

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

  4. C# by Anonymous Coward · · Score: 3, Funny

    As long as Microsoft continues to make C# and ASP.NET more capable and effective than anything else out there, I don't care if they throw IronRuby in the same trash bin as RegularRuby.

    1. Re:C# by MightyYar · · Score: 4, Funny

      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?

      --
      W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
    2. Re:C# by MightyYar · · Score: 2, Funny

      Yours was better than mine... more believable. That's why you guys get the big bucks.

      I tried to use .NET yesterday, but that's a funny story for another time.

      --
      W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
    3. Re:C# by 91degrees · · Score: 2, Interesting

      Yes, of course they copied Java. Java copied C++, C++ copied C, C copied B, B copied BCPL, BCPL copied CPL and CPL copied ALGOL.

      It's technology. We're trying to improve things not score points for originality. If a language has good features then copy them. C# added useful stuff like operator overloading and named arguments and lambdas. Plus a whole slew of other features that are actually pretty useful.

      And as far as "flooding the market" goes, MS had already flooded the market with MFC and Win32. .Net is way better tan either of them.

    4. Re:C# by MightyYar · · Score: 2, Funny

      I'll make fun of Hurd if it makes your dim green plastic soul shine just for a moment.

      --
      W..w..W - Willy Waterloo washes Warren Wiggins who is washing Waldo Woo.
  5. Inaccurate headline by Anonymous Coward · · Score: 5, Informative

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

  6. Harder than you think by cracauer · · Score: 4, Insightful

    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.

  7. What Oracle v. Google tells us by ciaran_o_riordan · · Score: 5, Interesting

    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.

    1. Re:What Oracle v. Google tells us by perlchild · · Score: 3, Interesting

      They wouldn't have been at risk from the copyrights and trademarks, but just how would they have avoided the patents?

    2. Re:What Oracle v. Google tells us by Anonymous Coward · · Score: 2, Insightful

      I don't think you have it quite right. From what I can tell, the issue is that Google implemented their own "JVM" in the form of the Dalvik VM. They claim compatibility with java, even though it's not technically a strict J2SE implementation, meaning it's NOT covered by the patent grant. They used the open source version of the java libraries from the Apache Harmony Project as I understand it. Where they went wrong was by adding their own libraries, and removing the bits they didn't want (AWT, Swing). So now they've effectively muddied the JVM waters. To develop android you have to use their Dalvik VM, but you're still writing java? How does that work? Is Dalvik sanctioned by Oracle? Nope!

      As much as I hate to say it, I think Google screwed up. Instead of paying the license fee like everyone else for J2ME, they decided to build their own VM and say, 'Hey,it's not really java, it's just java syntax. You can't charge us for that!' They then proceeded to wholesale ripoff the standard libraries and even go so far in their marketing speak to promote android development as using Java(TM). Oracle is totally justified IMO - Google was trying to skirt the rules and got caught. Time to pay up. If MS did this (and they did, back in the late 90's_ they were hung out to dry by Sun. Though there are differences in this case, the same principal remains: They tried to dilute the Java ecosystem with their own brand, and now they're getting called out on it.

    3. Re:What Oracle v. Google tells us by yyxx · · Score: 2, Informative

      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.

      Yes, they would have. You only get a patent grant if you provide a full J2SE implementation, which would have been totally unreasonable on a phone. Merely building on top of the GPL'ed version is not enough.

  8. Re:Good by bonch · · Score: 3, Funny

    Hard to argue with such a well-researched, fact-based conclusion.

  9. Re:IronRuby by bbtom · · Score: 4, Interesting

    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.

    --
    catch (HumourFailureException e) { e.user.send("You, sir, are a humourless idiot."); }
  10. Story title fail by Com2Kid · · Score: 2, Insightful

    "Microsoft may back off of dynamic .NET languages" would be more appropriate.

    Sad to hear though, I just started a project with IronPython.

  11. Confusion likely in Programming sphere by jitendraharlalka · · Score: 2, Insightful

    Oracle's legal action against Google over Android has already created confusion among developers about the future of Java as a platform. And, if Oracle is to able to stop Google from developing Android, Java will likely be avoided by any large companies for their new product. And, now this news that M$ might give up developing .NET any further adds to serve more confusion. With the recent news, there is another programming area likely to be severely hit i.e., the development of Mono. If .NET is gonna stop, it would be difficult to justify any development on Mono. Seems RMS was right again this time in opposing Mono from the very beginning. Only good thing this would serve in long term is more interest of developers in languages like Python, Perl. But, the present developments will definitely add so much of chaos to the programming sphere.

    1. Re:Confusion likely in Programming sphere by obijuanvaldez · · Score: 4, Informative

      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.

  12. Re:BrainFuck by Lunix+Nutcase · · Score: 2, Informative
  13. So he was a _PM_? by melted · · Score: 3, Funny

    Then nothing was really lost with his departure. All Microsoft PMs do is sit in the meetings, "manage schedule", "report status", and take credit for devs' work. What's even more insane is that in some teams PM/Dev ratio is 1:1. So that remaining dev (assuming he was, in fact, a dev) has just become twice as productive, due to the decrease in the number of meetings on his calendar.

  14. Multiple Languages With .Net Always a Pipe Dream by segedunum · · Score: 3, Insightful

    While this is slightly different, creating dynamic language environments on top of .Net, language neutrality in .Net has always been a myth. It's why there is only one language for .Net in C# and how VB.Net has become totally pointless because it's merely a syntactically different but identical .Net language. After attempts at those languages failed, such as those by ActiveState, we then got reasonably API compatible Ruby and Python environments being developed on top of .Net. Unfortunately, people already had API compatible versions of Ruby and Python - the official ones - and as a result no one has seen fit to run anything under a .Net Ruby or Python environment en masse. Environments like JRuby just clouded the landscape still further. All Microsoft really wants to do is try and get a critical mass of developers deploying to their versions of Ruby and Python probably for embrace and extend, and there is no sign that this is happening. They're trying to keep on with PHP because it's still the dominant web scripting language that they need for Azure to look semi-credible, but this is likely to meet a similar fate for the same reasons.

    The one environment that Microsoft should have created on top of .Net they simply didn't do. They should have created a rapid application development environment on top of .Net, free of the strict confines of C# and object oriented development, that aimed to be at least API compatible with classical VB so people merely had to recompile - as they had always been able to do. Alas, all that Microsoft did was force developers to throw lots of lines of existing code down the drain if they wanted to upgrade or either stay on the platforms they were on permanently or convert their applications to web based ones, which many did.

    Microsoft don't appear to have learned a thing after ten years of .Net.

  15. Ignorance, mostly. by Anonymous Coward · · Score: 5, Interesting

    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.

    1. Re:Ignorance, mostly. by rpresser · · Score: 2, Informative

      You conveniently omit "languages" -- really, glorified macro platforms -- like ASP and ColdFusion, which were a big if not bigger influence on PHP than Perl ever was. And ASP was ... guess who? Microsoft.

      (Damn. I was gonna moderate on this story, but couldn't resist replying.)

    2. Re:Ignorance, mostly. by Joey+Vegetables · · Score: 2, Interesting

      What would you consider to be a "better and easier static" alternative to, say, Python?

    3. Re:Ignorance, mostly. by gbjbaanb · · Score: 2, Insightful

      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.

      got to disagree with this bit. ASP was released and the sloppy web programmers who used to slap something together were joined by a legion of Visual Basic programmers who used to throw something together, but thought they were uber-developers because they were employed to write this kind of code.

      Sure, ASP.NET is better, and all the old VB devs have faded away somewhere, but I don't think the number of C#/VB.NET devs working on ASP.NET apps is that much better the the old lot.

      There is a technical argument in favour of dynamic languages - and that's RAD. You can fiddle with the language as you go, "develop in the debugger" kind of programming. I'm not saying this is a good thing, but if you don't have the discipline to do it properly (like the old C/C++ dev would) then this provides you with an easy entry to programming. Hopefully you'll learn and become a professional dev from that.

    4. Re:Ignorance, mostly. by IamTheRealMike · · Score: 2, Interesting

      D (version 2). It has most of the flexibility of Python, but lacking 90% of the danger and general lack of clarity that typifies Python code.

    5. Re:Ignorance, mostly. by Just+Some+Guy · · Score: 3, Interesting

      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.

      Speaking of ignorance; pot, meet kettle! Dynamic languages became widely used mainly because they're so damn nice to use. I have a lot of background in C, functional languages, and various assembler dialects (which are really the ultimate in dynamic languages!), but I'd rather use Python than any of them for routine development.

      What specifically don't you like about dynamicism? Most of the complaints I've heard are that it forces you to write all the checks yourself!, as though the kinds of constraints you'd need in a static language are required (or even desirable) in a dynamic language.

      For example, I love duck typing. I can write a class that implements read() and pass it to almost any function that expects to receive a file-type object as an argument. I can write def add(x,y): return x+y and know that it will do the right thing whether I pass in ints, floats, or strings. (Side note: dynamic typing is not the same as weak typing; you can't add 1+"2" because those types are incompatible. I can't stand working in languages that attempt to do what I mean by guessing).

      So a static language adherent might complain that my definition of add doesn't check for every possible combination of input datatypes. That's kind of the point, though; in Python you wouldn't want to prevalidate everything. Just run the operation and let it do its thing. If you've passed in, say, a file handle and a PDF, then the "+" operation will fail, but every sane case will actually work as you'd expect.

      I guess I can summarize it this way: the only type errors I've ever received while programming in Python have been when I passed None to a function by accident because (for example) a database call returned an empty set. In each of those cases, I'd have gotten the same kind of error if I'd accidentally passed a null pointer to a C function - except that the Python program threw an exception instead of opening a security vulnerability.

      I can program in plenty of static languages. Now that I'm far enough along in my career that I can pick my own tools, I almost always choose not to. I love dynamic languages and I won't voluntarily go back.

      --
      Dewey, what part of this looks like authorities should be involved?
    6. Re:Ignorance, mostly. by ChronoFish · · Score: 2, Insightful

      Syntactically PHP is actually a lot more like C/C++ than it is like Perl. It's basically a typeless "C/C++". It had a huge following because you could easily pepper HTML with embedded scripting - and hosting companies could offer PHP because it made for a convenient and sandbox. Yes you could easily kill a PHP script - but the PHP executable has always been stable (I've never seen the executable itself crash - nor have I ever seen PHP crash Apache or the OS - and I've been developing in PHP for 10 years now).

      I know I'm in the minority, but I came from C/C++ / Comp Sci background. After years of Motif programming I found PHP a real joy. I no longer had to solve programming language problems (memory management, garbage collection, STL template integration, etc). I just had to solve for the solution of the real problem.

      I think most "real developers" don't like PHP because it seems too easy. If you don't find it liberating you find it frustrating that you've spent so much of your life searching out malloc bugs - and anything that trivializes your agony is assumed to simply not be that powerful.

      Aside from image manipulation (2d/3d), there have been few problems that I've encountered on either the front or back-end that I couldn't solve in PHP that would have been easy (or even easier) to solve in another language. Typically the real problems - like large (millions of records) iterations, searching, or merges are easily solved by letting the database do it's job.

      It's true that there exists a huge nest of bad code written in PHP. I've never understood this as an argument against the language however. The person stating the fact usually claims that they are a "real" programmer - if so - then why is it that difficult to discipline yourself to write good code? Taking the simple approach of following a basic MVP paradigm (with or without a formal framework) solves 90% of the rat's nest issues that encompass the "bad" PHP code. PHP can be as structured and well written as any language - it just takes a (very little) bit of discipline.

      -CF

    7. Re:Ignorance, mostly. by xMilkmanDanx · · Score: 3, Informative

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

    8. Re:Ignorance, mostly. by Mongoose+Disciple · · Score: 2, Informative

      ASP wasn't even released until 2002. That's even two years after PHP 4.

      ASP.NET, maybe. Old school ASP was circa 1998.

    9. Re:Ignorance, mostly. by JDAustin · · Score: 2, Informative

      ASP wasn't even released until 2002. That's even two years after PHP 4.

      No idiot...ASP was originally released with IIS in 1996. ASP is interpreted/scripted while ASP.NET was released in 2002. ASP and ASP.net share as much in common as VB6 and VB.Net do..ie language syntax and name only. Everything else is different.

  16. Re:Do Microsoft products use .NET? by lena_10326 · · Score: 4, Interesting

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

    --
    Camping on quad since 1996.
  17. Re:Multiple Languages With .Net Always a Pipe Drea by segedunum · · Score: 3, Interesting

    Microsoft killed old-school VB/VBA development and forced a generation of terrible developers to move, however relucantly, towards object oriented programming by accident.

    Nope, it definitely wasn't an accident so I wasn't implying that. The purposefully did it. Quite why they did it I cannot fathom because it's just hurt and fragmented their developer base that grew to an extremely critical mass during the nineties. Maybe the MSDN guys got greedy and thought they could make money from getting people to rewrite everything, I don't know.

    I know people sniped at VB, but the fact is that probably billions of lines of code are sitting around written in it and it's the only rapid development platform Microsoft and Windows has. Throwing that away was not a smart move.

  18. Re:Do Microsoft products use .NET? by Richard_at_work · · Score: 2, Informative

    Yes, most of their core serverside business platforms are based on .Net in whole or in part, including Dyanmics CRM, SharePoint and SQL Server 2008 (the core has a dependency, while the additional services are also largely .Net based these days, including Reporting Services).

  19. Well if their website is any indication by Dunbal · · Score: 2, Insightful

    Microsoft is a company that is trying to point in all directions at once. This wouldn't be the first idea they have poured time and effort into, only to drop it. I am sick and tired of having to learn new development techniques just because Microsoft thinks that this year MFC/WPF/XNA/.NET/C#/F# is going to be **IT**, skimming through thousands of completely unhelpful reference pages on MSDN that merely hint at what functions/objects/libraries/tools are supposed to do but point to other pages in circular references worse than any 1990's porn sites.

    Programming is supposed to make life easier, not harder. Microsoft is the expert in obfuscated standards, obfuscated libraries, and especially obfuscated documentation. It's a wonder they get anything done at all.

    --
    Seven puppies were harmed during the making of this post.
  20. Support Parrot by acid06 · · Score: 2

    And this is why I believe there should be more people supporting the Parrot VM.
    It is already usable and could support a lot more languages decently with better community support.

    1. Re:Support Parrot by Lennie · · Score: 2

      Agree.

      --
      New things are always on the horizon
  21. Not really by thasmudyan · · Score: 3, Insightful

    Microsoft management knows full well that the only way to stay on top of their huge bloated codebase and architecture is to continue along the path of managed code. The only thing they're not fond of are dynamic languages, pure and simple. Support for dynamic languages was added to the .NET runtime very late in the game, and begrudgingly at that. Their current development and runtime environments rely on huge amounts of auto-generated boilerplate glue without which the simplest tasks wouldn't be possible.

    The reasons for this are probably largely historical, because there are still a lot of people from the old COM days working at MS. There are fact-based arguments as well: Dynamic languages tend to be more concise but are more difficult to automatically evaluate and optimize, especially considering the way Microsoft is relying on interface contracts and access policies (all of which are either generated by static language code or in turn serve to generate such code). Besides, none of the teams working on those much-needed tools and design-helpers wants to be put out of a job, so of course they have to stay firmly committed to their huge heap of statically generated code.

    A few years ago some Microsoftie told me about a new research OS they were working on, it was completely .NET-based and probably still reflects how MS would like Windows to be if they could start over from scratch today. I believe the project's name was Singularity, I don't know if it still exists. Anyway, the whole point of the OS was its completely static architecture. There was no support for dynamic languages, all executables were statically linked and completely rigid. There was no self-modification allowed for any application and as far as I remember applications couldn't even dynamically load libraries at runtime. So, in a way, they already made clear which road they are going to go down. Dynamic languages aren't in the mix anymore, but managed code will stay around for a long time at Microsoft.

  22. Planned obsolescence by alexmin · · Score: 2, Insightful

    I would not be too surprised if MS stops pushing .NET in near future and instead pitches "new and improved" stuff. Totally incompatible with .NET, of course. I believe this is their way to keep windows developers busy re-learning new ways to do old tricks and too busy to look at MS competitors. .NET is 10 years old now btw. Remember VB6, DDE, OLE and WIN32? Yea, I do.

  23. Only on Unix, you say? by ratboy666 · · Score: 3, Interesting

    "too bad all the Java application servers blow on anything but Unix... so in reality... with Java you get Unix OSs"

    J2EE application servers are available on Windows Server, Solaris, HP-UX, RedHat Linux (and other Linux distributions), AIX, OS/2, OS/390, OS/400.

    Are you telling me that the two Mainframe servers aren't stable? That the Linux (JBoss or WebSphere) isn't stable? And, if a J2EE server (WebSphere or WebLogic) is blowing up on Windows Server, I would really like to know.

    Back up your claim, please.

    --
    Just another "Cubible(sic) Joe" 2 17 3061
  24. Still need help with VM tail call support by ratboy666 · · Score: 2, Interesting

    Thanks for the description. I definitely see your point. Marking a tail call to allow the elimination of a stack frame, and allow static verification.

    But, mutual recursive functions that are compiled separately cannot be so marked. Of course, attempting to check for stack non-growth is probably not included -- the call can only be marked as a tail call if it is within the same source unit, and when doing the analysis prior to marking it has already been determined that no stack growth would be needed. The tail call marking can, however, be used to suppress any frame reallocation. By definition, there will then be no frame growth, as all bound variables simply have their previous binding.

    Still, this appears a complicated way of doing it.

    Consider:

    func() { ... func(); }

    can simply be replaced by:

    func() { for(;;) { ... } }

    and, the second case is already accommodated by the compiler. Of course the parameters may need to be rebound, without rebinding anything else. Which (since no further frames are to be created) is as simple as:

    func(int p) { ... func(new_p); }

    becomes

    func(int p) { int p_old; for(;;) { ... p_old = p; p = new_p; } }

    (or thereabouts, note that you can use the equivalent to C's "continue" to good effect). Anyway, with a tail call flag, I would assume it looks like this:

    func(int p) { ... func(new_p, tail_call=true); }

    Note that we are still missing somewhere to stuff the previous binding for p (old_p) on the tail call. In the "simplistic" approach, this storage is rather explicit. As far as flow is concerned, I still don't quite understand -- the compiler had to be aware anyway. So, I still don't understand why it is considered a feature.

    Although I haven't really thought about it, maybe inter-method tail calls? Maybe someone with Microsoft .Net VM experience can jump in and explain (I don't have the time to plow into Mono right now).

    Since I generally compile to C, and the second method requires poking the call machinery, I tend to like my original formulation. Still, .Net is a VM and not a compiler (although it does JIT compile, right?), so it's not a big deal.

    (What is likely is that I have missed something, possibly obvious, and need enlightenment).

    Thanks in advance
    Ratboy666 - deep down and full access

    --
    Just another "Cubible(sic) Joe" 2 17 3061