Microsoft May Back Off of .NET Languages
443
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."
What Oracle v. Google tells us (Score:5, Interesting)
With Oracle attacking Google over Java patents [swpat.org]...
One lesson to be drawn, as suggested by Miguel de Icaza,[4] is that people should move to Mono and C# because Microsoft's patent terms are better than Sun's.
On the other hand, one could draw the lesson that it's foolish to use languages / platforms controlled by companies that use patents aggressively.
Another point is that if Google had used IcedTea (the GPL'd version of Java), they never would have been at risk from Sun/Oracle's patents.
Re:IronRuby (Score:5, 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.
Re:What Oracle v. Google tells us (Score:4, Interesting)
They wouldn't have been at risk from the copyrights and trademarks, but just how would they have avoided the patents?
Re:Getting screwed in both directions (Score:3, Interesting)
Re:Shit. (Score:1, Interesting)
You may laugh but I get paid twice what normal Java monkeys and C# monkeys get. Why? LEGACY SALARY. I just fake a cold and they rush in with fresh printed money. Cushy safe job. No teenie nerds thinking they know it all with Java and C#. I know for a fact they WONT and DONT do COBOL that's why I can command such large fees and feel comfortable in my job. NO student know it alls, no WoW gamer know it alls. BILLIONS of lines of code in use today, not just legacy old code but also NEW code in COBOL. Want a safer job environment in development? do RPG, COBOL etc.
Ignorance, mostly. (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.
Re:Getting screwed in both directions (Score:5, 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.
Re:Getting screwed in both directions (Score:2, Interesting)
Re:Do Microsoft products use .NET? (Score:5, Interesting)
If you search for a Microsoft job, most are working with C# and C++. I interviewed at Microsoft in the past and there appears to be an extreme preference among their programmers to use C# because the majority of Bing/MSN code is in C#. I think Microsoft lacked the commitment because the prototypical Microsoft developer isn't interested in Ruby or Python. Those languages come with the baggage of social stigma: rogue developer, "non-enterprise", web monkey, low pay, low performance, 1 man startups, and "only for prototypes". It was clear to me developers inside Microsoft prefer C#.
Re:C# (Score:2, Interesting)
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.
Re:Getting screwed in both directions (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.
Re:Using them? (Score:5, Interesting)
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...
Re:Multiple Languages With .Net Always a Pipe Drea (Score:4, Interesting)
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.
Re:Ignorance, mostly. (Score:3, Interesting)
Re:Ignorance, mostly. (Score:3, Interesting)
Re:Ignorance, mostly. (Score:4, 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.
Re:Getting screwed in both directions (Score:3, 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).
Re: continuations vs. yield return (Score:1, Interesting)
I've never used Ruby or seen its continuations, but it's worth mentioning that C# has a "yield return" statement used in IEnumerator to return a value and save the current execution state in the enumerator object. This allows the the next call to the enumerator to restore the state, so it's obvious that you could implement a setjmp/longjmp with yield return plus try/finally to invalidate the jmpbufs when the calling function returns.
Since setjmp/longjmp are possible, surely you could implement Ruby's continuations. If necessary, you could even allocate each function's call stack on the heap so that jmpbufs don't have to be invalidated when the calling function returns.
Re:Getting screwed in both directions (Score:4, 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?
Re:Getting screwed in both directions (Score:3, 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.
Re:Getting screwed in both directions (Score:2, Interesting)
too bad all the Java application servers blow on anything but Unix... so in reality... with Java you get Unix OSs.
Only on Unix, you say? (Score:4, 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.
Still need help with VM tail call support (Score:3, 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