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."
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."); }
I've been hoping for COBOL.NET.
RIP America
July 4, 1776 - September 11, 2001
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."
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.
The headline "Microsoft May Back Off dynamic .NET Languages" would be better?
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.
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.
Expert in software patents or patent law? Contribute to the ESP wiki!
Hard to argue with such a well-researched, fact-based conclusion.
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."); }
"Microsoft may back off of dynamic .NET languages" would be more appropriate.
Sad to hear though, I just started a project with IronPython.
Need help treating your acne? Come here!
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.
Whatdo you mean?
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.
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.
.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.
.Net.
The one environment that Microsoft should have created on top of
Microsoft don't appear to have learned a thing after ten years of
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.
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.
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.
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).
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.
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.
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.
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.
"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
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