Microsoft's dynamic languages on forced diet Microsoft appears to be backing off its initial commitment for .NETized versions of dynamic languages. Jimmy Schementi, the program manager for Microsoft's implementation of Ruby, called IronRuby, has left the company as the IronRuby team has been run out town and reallocated. Schementi has blogged about a "serious lack of …
It looks like MS is falling in the same hole as some other projects have. It is not enough to just put the code on a server and say a few words like "community". You really have to nurture any efforts like this to make them work.
Abandoning software is the same as abandoning a puppy. It's the wimp's way out for those without the conviction to kill it.
It was a really dumb idea afterall. Why put the effort into learning Ruby if you've got no Rails?
They've been adding dynamic-style features to C# for the last few years, and it's obvious that they're going to focus on improving this side of the language. Add features to the language that their development community know and love in order to allow it to compete with Python (and to a lesser extent Ruby).
Though to be honest I personally believe that the biggest benefit of most of these 'dynamic' languages is that they're interpreted. That, combined with a TDD-style of development allow you to work very efficiently. Which, I should add, should be possible to implement in C# (or a subset thereof).
As for scripting languages - MS have Powershell, which is very very powerful, though the target group is different (system admins not developers).
"Though to be honest I personally believe that the biggest benefit of most of these 'dynamic' languages is that they're interpreted."
That's an irrelevant distinction.
You are missing the dynamic aspects, of which there are: high flexibility, rapid writing with little syntactic baggage, weak and/or duck typing, compact, polymorphic and often implied code, easy-to-use reflection as compared to the "traditional" enterprise languages. Not to mention closures, a strong trend to functional programmiong and facilities to patch up stuff at runtime.
Course, runtime errors are more likely, so you better use asserts liberally.
On the otherhand, This is Fantastic News. The sooner this (& Slitherlight) die a truly horrible death the better.
Why?
Simple (just like those pesky meerkats) really.
Lock-in.
There is more to IT than a Microsoft only world. Don't even try to talk about mono. More & more Linux devs are shunning this. It is slowly withereing away. .NET should follow it ASAP.
Paris because even she knows when to stop flogging a dead horse.
I'd love to see an end to .NET.
It is a loathsome thing that can turn the installation of simple program into hours of work.
Wrong (or no) version of .net? The right version gets fetched: a large and tedious download. This is then followed by an installation which (mostly silently) takes an unbelievable amount of time.
Whatever .net maybe for the developer, Microsoft made one big mistake: they never bothered to inform the end user as to why would want want it, leaving most of us convinced that it is just a waste of time and space.
"This program requires MS .NET version blah blah blah" --- better find another one then.
Besides the ms-pl license... There's a main branch of ruby and python for interested developers to work on. "iron" versions are a double niche -- microsoft specific* while main versions are portable *including* windows. And a second niche because they're for .net ... Jython (python for java), ironpython, well.. Plenty of people just don't see the need for contributing for python (or ruby) on top of another layer when it's portable to the "bare metal" os.
..*yeah i realize they probably play nice with mono and such and not truly windows-specific. Bear with me...
The Common Language Environment and Common Language Runtime.
Which Visual Studio supported languages produce *directly* executable code by default now?
Be clear. If you go with an MS version of *any* language *and* you want portability you're going to have to work *damm* hard for it. You'll fine tooth comb startup settings, library dependencies and naming conventions and you'd better RTFM. All of them.
If you're a Windows lifer then commit to their platform specific languages and tools and accept you're spending the rest of your career working on them, so get comfortable.
Or you could just use a version standard version from some other supplier.
"How about C++, still the language for *real* Windows applications and systems programming de rigueur."
Thanks for that. I suspected C/C++ would be the the #1 compiled to bare hardware exception. As to how much of that code is actually *using* those C++ specific features that would be another story.
I think it says a lot that MS espouse all sorts of weird and wonderful (and proprietary) languages for *everyone* else but when it comes do changing *their* core (or real performance issues) it's straight for the old faithful.
Why do MS insist on making their own versions of languages that are already out there, and that already have a firm grounding of developers and users? As has been mentioned previously, the normal versions work on Windows anyway. Making a custom version is pretty much a sure-fire way of failing.
Oh, duh!!! Of course - they want to try and lock you into their OS. How silly fof me.
Surely beginning of the end for .NET merely means a morph into the start of something Beta and more Advanced Astute and Appropriate.
And Dedicated Smarter InterNetworking with "Just BetaTesting PerlyGatesPython Security CodedD CHunnels. ...... Alternative Underground Channels."** rapidly turns Sinning into a Global Passion Play, which probably every Woman will tell you, is quite alien to child-like Primative Man, both offensively arrogant and XSSXXXXually ignorant, and as a result do they render themselves extraordinarily poorly schooled and too inexperienced to deliver engaging and drivering satisfaction and exquisite pleasures. ........ which is real sad and quite bad.
But you can be assured that the methodology and binary algorithms for applications of an acceptable and most agreeable, mutually beneficial solution are being worked upon and trailed and trialled in a multitude of novel systems operations and virtually real simulations ... for Semantic Scene Stimulation/Lasting Projection with Revised Provisional Input ..... Core Source Stream
* Very naughty boys and girls can read more on IT here .... Posted by AmanfromMars on 8/11/2010 11:45:25 AM ... http://thedailybell.com/1283/UK-Central-Bank-Loses-Credibility.html
It is unnatural and naive to think, that with the sophisticated and intrusive and disruptive nature of common communications today, that the future will be runs as badly as the past was by the present controllers, who appear to have defaulted to Creating Chaos as a means of Exercising Control, which is real weird.
In fact, is it surely a certifiable madness and festering self -destructive badness in many, if not all, Status Quo Establishments ..... Privatised International Power Cliques.
IIRC from a 10 minute look the syntax of .net python's "import" were different from normal Python. Thus ensuring _no_ compatibility. Unlike Jython where simple scripts can be identical IF Jython has implemented the equivalent modules and you aint fiddlin with Java.
Kind of never bothered looking again after that.
Microsoft was interested in enabling dynamic languages in .Net and sponsored enough development to be sure that the CLR would support them. Beyond that, I don't see that they would have any real motivation to move these languages forward: They won't generate income and MS won't make much internal use of them.
"When my manager asked me, 'what else would you want to work on other than Ruby,' I started looking for a new job outside Microsoft."
How are they supposed to pay the salary if the work doesn't generate revenue?
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
